​

The Reassigned Numbers Database (RND)

​

The verdict is a date comparison, not a membership test

{
  "data": {
    "status": "no",
    "safe_harbor": true,
    "last_disconnect_date": "2026-03-14",
    "consent_date": "2026-06-01",
    "feed_synced": true,
    "reason": "No permanent disconnect after the consent date; the FCC reassigned-number safe harbor applies — safe to contact."
  },
  "meta": {
    "request_id": "req_01J9A7XK4M",
    "timestamp": "2026-09-15T11:30:00Z"
  }
}

• status — yes / no / no_data exactly as above.
• safe_harbor — true only for status: "no". Branch on this one boolean; treat anything else as “stop.”
• feed_synced — false means no RND snapshot is loaded in the deployment, so every verdict degrades to no_data. The platform never asserts a safe harbor it has not actually queried — always read this field before trusting a no verdict.

​

Where the snapshot comes from and how it loads

​

The tenant-operated toggle

curl -X PUT https://api.orbit.devotel.io/api/v1/compliance/rnd/settings \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

{
  "data": {
    "enabled": true,
    "feed_synced": true
  },
  "meta": {
    "request_id": "req_01J9A8XK5N",
    "timestamp": "2026-09-15T11:35:00Z"
  }
}

• Read the flag with GET /api/v1/compliance/rnd/settings — the response’s feed_synced tells you whether a snapshot is loaded before you decide to enable.
• Write it with PUT /api/v1/compliance/rnd/settings ({ "enabled": true|false }). Owner or admin only; an enabled: true write while no snapshot is loaded is refused with 409 RND_FEED_NOT_CONFIGURED — enabling an empty gate would present an inert control as operational protection. Disabling is always permitted.
• Check a destination with

GET /api/v1/compliance/rnd/check?phone=<e164>&consent_date=<YYYY-MM-DD>

​

The two surfaces that consume the verdict

• The predictive dialer. Every paced dial and callback re-checks destination admissibility right before the call originates (see Dialer pacing). With a snapshot loaded and your flag on, a yes verdict blocks the dial with reason rnd_reassigned. This is the automatic gate — no per-call endpoint request needed.
• The API pre-send gate — GET /api/v1/compliance/rnd/check. Any authenticated role can read this on demand: pre-flight a single destination before its own send, or batch a list ahead of a campaign. It is the manual counterpart of the dialer’s automatic gate, and the scrub it applies is identical.

​

Implementation note: the two-process duplication (not operator contract)

​

RND vs. DNC vs. deactivation scrub — three orthogonal answers

​

Evidence: what the scrub leaves for counsel and audits

• Every check call — each /rnd/check evaluation (and every denied attempt while the flag is off) lands an audit entry carrying the verdict, the consent date it was evaluated against, and the actor. The phone number is truncated in the entry to avoid stamping full PII into the chain.
• Every toggle change — flag flips land an audit entry with the new state; an enable blocked by the missing snapshot 409 is audited as such, so reviews see blocked attempts as well as allowed ones.
• Every blocked dial — a dialer block on rnd_reassigned is logged alongside the rest of the send-gate chain, so a scrubbed batch has a per-contact reason rather than a silent drop.

​

See also

• Send gates — the endpoint wiring surface and the rest of the gate stack
• Country requirements — per-country compliance attachment rules
• Deactivation scrubbing — the carrier-churn hygiene gate RND complements
• Consent and suppression model — the consent record the consent_date parameter reads from
• Outbound send gating — the full gate chain the RND check slots into
• Dialer pacing model — where the automatic RND gate fires on paced calls
• Audit ledger model — the evidence chain the scrub writes to
• Legal holds guide — preserving your hold scope