> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# RND Scrub: FCC Reassigned Numbers Database Reference

> The FCC Reassigned Numbers Database (RND) pre-contact scrub — the per-organization opt-in flag, the single-number check endpoint and its verdict semantics, feed-sync and staleness handling, and how the safe-harbor verdict fits your TCPA posture.

# 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](/guides/rnd-safe-harbor-preflight).

All endpoints below are rooted at
`https://api.orbit.devotel.io/api/v1/compliance`.

<Warning>
  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.
</Warning>

***

## 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](https://www.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](/compliance/dnc-scrub) and the
[carrier deactivation scrub](/compliance/deactivation-scrub), which
answer the registry and line-status questions (see
[Send Gates](/compliance/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:

```json theme={null}
{
  "data": {
    "enabled": true,
    "feed_synced": true
  }
}
```

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:

| Parameter      | Shape                     | Meaning                                                  |
| -------------- | ------------------------- | -------------------------------------------------------- |
| `phone`        | E.164 (`+` + 7-15 digits) | Destination to scrub                                     |
| `consent_date` | `YYYY-MM-DD`              | Date you obtained or last verified prior-express consent |

Both are required; a malformed value returns HTTP 422 with the failing
field named in `details`.

Response envelope:

```json theme={null}
{
  "data": {
    "status": "no",
    "safe_harbor": true,
    "last_disconnect_date": "2025-11-02",
    "consent_date": "2026-08-15",
    "feed_synced": true,
    "reason": "No permanent disconnect after the consent date; the FCC reassigned-number safe harbor applies — safe to contact."
  }
}
```

| Field                  | Type                     | Meaning                                                                         |
| ---------------------- | ------------------------ | ------------------------------------------------------------------------------- |
| `status`               | `yes` / `no` / `no_data` | The FCC verdict for the (number, consent-date) pair                             |
| `safe_harbor`          | boolean                  | True **only** when `status` is `no`                                             |
| `last_disconnect_date` | ISO date or `null`       | Most-recent permanent disconnect on record; the date the comparison ran against |
| `consent_date`         | ISO date                 | The date the verdict was evaluated against (echo)                               |
| `feed_synced`          | boolean                  | Whether an ingested RND snapshot backed this verdict                            |
| `reason`               | string                   | One-sentence explanation suitable for an audit log                              |

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](/guides/rnd-safe-harbor-preflight).

***

## 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](/compliance/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](/compliance/send-gates).

***

See also:

* [RND Safe-Harbor Pre-Flight guide](/guides/rnd-safe-harbor-preflight) —
  the campaign workflow for this scrub.
* [Send Gates](/compliance/send-gates) — all send-time gates, with the
  RND leg's position on the page.
* [DNC Scrubbing](/compliance/dnc-scrub) — the opt-out registry layer.
* [Carrier Deactivation Scrub](/compliance/deactivation-scrub) — the
  carrier disconnect/churn layer.
* [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) — the
  layer a `yes` verdict routes onto.
* [API Reference → Compliance](/api-reference/endpoints/compliance) —
  full request/response schemas.