Skip to main content

​
RND Scrub: FCC Reassigned Numbers Database Reference

This page is the reference for Orbit’s Reassigned Numbers Database (RND) scrub: what the endpoints do, what every field in the response means, and how the opt-in flag and feed sync govern the verdicts you get back. For the end-to-end workflow — building a pre-campaign batch, routing verdicts out of your send audience, and re-scrubbing stale lists — see the RND safe-harbor pre-flight guide. All endpoints below are rooted at https://api.orbit.devotel.io/api/v1/compliance.
This page documents Orbit’s tenant-owned controls. It is not legal advice. Whether contacting a given number is restricted depends on your jurisdiction, your recipients, and what you send — confirm with qualified counsel.

​
The FCC RND and why pre-contact scrubbing matters

Under the TCPA, consent follows the subscriber, not the phone number. When a carrier permanently disconnects a number, the carrier can reassign it to a new subscriber — and your prior-express consent for the original subscriber stops covering that destination. Contacting the new subscriber is a fresh TCPA exposure (47 U.S.C. § 227). The FCC’s Reassigned Numbers Database (reassigned.us, 47 CFR § 64.1200(m)) aggregates carrier-reported permanent-disconnect dates so a caller can answer one question before every re-contact: was this number permanently disconnected after the date I obtained consent? When the database answers “No,” the FCC’s safe harbor shields you from reassigned-number liability even if the number turns out to have been reassigned. Orbit exposes that evaluation as a read-only lookup. A check never performs a send — it is the gate your own send path consults before outbound SMS or voice initiation. Scrubbing is one of the compliance controls your organization owns and enables; run it alongside the DNC scrub and the carrier deactivation scrub, which answer the registry and line-status questions (see Send Gates for how all of these feed the send-time posture).

​
The opt-in flag lifecycle

The scrub is gated behind a per-organization opt-in flag — organizations.settings.rnd_scrub_enabled, default off. Two endpoints manage it:

​
GET /rnd/settings — read the flag

Returns the current flag state plus feed_synced, which reports whether an RND disconnect snapshot is actually loaded:
Any authenticated role may read it. Read the gate state before scrubbing: while enabled is false the check endpoint returns HTTP 403 with code RND_SCRUB_NOT_ENABLED, and while feed_synced is false every verdict degrades to no_data (below). Denied checks are audit-logged so a compliance review sees the attempted scrub and the gate-state at the time of the call.

​
PUT /rnd/settings — set the flag

Body: { "enabled": true } (strict schema — unknown keys are a 422). Owner/admin only; rate-limited to 20 writes per minute. Lifecycle rules:
  • Enabling is refused while no feed is connected — HTTP 409 with code RND_FEED_NOT_CONFIGURED. The platform does not offer a compliance control that performs no screening. Disabling is always allowed, so a tenant that enabled earlier can back out at any time.
  • A successful write is auditable. Setting the flag writes an audit entry naming the actor and the new value; blocked enable attempts are audited with the RND_FEED_NOT_CONFIGURED reason.
  • The read-back is immediate. The flag lives on the same organization row the check gate reads, so a write takes effect on the next call.

​
The single-number check and the batch pattern

​
GET /rnd/check

Query parameters: Both are required; a malformed value returns HTTP 422 with the failing field named in details. Response envelope:
Verdict semantics:
  • yes — the number was permanently disconnected after the consent date and may have been reassigned. No safe harbor; suppress the destination.
  • no — no permanent disconnect after the consent date. The safe harbor applies.
  • no_data — the synced feed has no record for the number, or no feed is loaded. No safe harbor; treat as unknown.
Every check — allowed or denied — is audit-logged with the verdict and consent date, and the phone number is truncated (first 5 digits → ****) in the audit details.

​
Batch and pre-campaign flow

There is no batch endpoint; a batch is a loop over the single check at the authenticated-read budget (120 requests/minute per organization). The pre-campaign sequence — build the segment, resolve a consent date per recipient, check the gate, loop, and route yes/no_data out of the audience — is walked through in the pre-flight guide.

​
Feed sync and staleness

The RND is a paid subscription (database administrator: SomosGov / reassigned.us) that Orbit ingests as a snapshot. Two surfaces report sync state:
  • GET /rnd/settings → feed_synced
  • GET /rnd/check → feed_synced on every verdict
Staleness rules:
  • While no snapshot is loaded, enabling the flag is refused (409) and every verdict is no_data with safe_harbor: false — the platform never asserts a safe harbor it has not actually queried.
  • A feed lookup failure degrades the same way — feed_synced: false, no_data, last_disconnect_date: null. A no_data verdict is not a pass; route per your own risk policy.
  • Carriers update the RND continuously, so a verdict ages out. For audiences held more than a couple of days, re-scrub before each send rather than trusting the verdict computed at audience-build time.

​
Safe-harbor interplay with your TCPA posture

The scrub is one tenant-owned control in the TCPA posture map (see Posture Overview). Two properties to build on:
  1. safe_harbor: true follows status: "no" only. A run of clean no_data verdicts means the screen did not run — do not treat unknowns as cleared.
  2. The audit trail is the point. Every check records the verdict, safe_harbor, and consent date so a compliance review can prove the pre-contact check ran before the send went out.
Send-time gating — how the RND leg composes with quiet hours, DNC, RMD, and country-rate gates — is covered in Send Gates.
See also: