> ## 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. # Sends blocked by the reassigned-number gate — 422 MESSAGING_RND_REASSIGNED > What the reassigned-number refusal means, where it surfaces, how to confirm the reassignment with the RND lookup, the consent-evidence fixes that clear it, your tenant-owned posture toggle, and why blind retries never work. # Sends blocked by the reassigned-number gate A send refuses with HTTP 422 and code `MESSAGING_RND_REASSIGNED`. The reassigned-number (RND) scrub your organization enabled found that the destination number was permanently disconnected after the date your consent ledger records, so the number may now belong to a new subscriber and the send is refused before dispatch. This page walks what the refusal means, how to confirm the reassignment, and the paths that clear it. RND scrubbing is a tenant-owned control. Your organization opted in under Settings → Compliance; Orbit enforces the posture you set and records every block in your audit log. The posture decision, including disabling the scrub, is always yours. *** ## 1. What you see The send call returns: ```json theme={null} { "error": { "code": "MESSAGING_RND_REASSIGNED", "status": 422, "message": "Recipient number was permanently disconnected after the date consent was obtained and may have been reassigned to a new subscriber (FCC Reassigned Numbers Database). No TCPA safe harbor applies — confirm the number still belongs to the consenting party, or remove it.", "details": { "to": "+1312****", "channel": "sms", "last_disconnect_date": "2026-03-14" } }, "meta": { "request_id": "req_01J...", "timestamp": "2026-10-16T14:22:31.000Z" } } ``` `details.to` is the destination redacted to its first digits; the full identifier stays in your own records, not in the response. The refusal surfaces in three places: * **The send response** — the 422 above, for synchronous API sends. * **Campaign and flow sends** — the individual send is recorded as failed with this code in the campaign's failure view; the rest of the campaign continues. * **Message webhooks** — if you subscribe to message lifecycle events, the failure event for that send carries the same code. Every block also writes an audit row (Settings → Audit log) naming the channel and the refusal reason, so a compliance review can see what was refused and why. The gate applies to US (+1) SMS and MMS destinations on organizations that enabled the scrub. One-time-code sends to phone channels use a sibling guard, [`VERIFY_RND_REASSIGNED`](/troubleshooting/verify-otp), covered on its own page. *** ## 2. Why the gate exists When a number is permanently disconnected, the carrier eventually recycles it to a new subscriber. A message sent to a recycled number reaches a stranger who never consented to your traffic: a wrong-recipient exposure with no TCPA safe harbor. The FCC maintains the Reassigned Numbers Database (RND) so senders can check a number against permanent-disconnect records before contacting it (the 47 CFR § 64.1200(m) safe harbor), and your enabled scrub does exactly that on the send path: when a permanent disconnect on record post-dates the consent date in your ledger, no safe harbor applies and the send is refused. This refusal can only fire because your organization opted in. RND scrubbing defaults off; enabling it, and the strictness it applies to your sends, is a posture decision your compliance team owns. Orbit provides the control and enforces it faithfully; it does not mandate the posture. *** ## 3. Confirm the reassignment Run the lookup on the destination with the consent date you have on record: ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/compliance/rnd/check?phone=%2B13125550142&consent_date=2025-11-02" \ -H "X-API-Key: dv_live_sk_..." ``` The response data carries the verdict: | Field | Meaning | | - | - | | `status: "yes"` | A permanent disconnect is on record **after** `consent_date`. No safe harbor — this is the blocked state. | | `status: "no"` | No disconnect after `consent_date`; the FCC safe harbor applies and sends proceed. | | `status: "no_data"` | No record either way. Sends proceed, but treat it as absence of evidence, not a clearance. | | `last_disconnect_date` | The most recent permanent-disconnect date on record; compare it against your last verified-consent date. | The comparison is the whole decision: * **Disconnect after your consent date** → the consent you hold predates the reassignment risk; take a fix path from [Section 4](#4-fix-paths). * **Disconnect before a newer consent date you hold** → your ledger is stale. The gate evaluated the latest grant it could find; record the newer grant (fix path B) so the evaluation uses it. * **No disconnect on record** → the 422 you received is not this gate's current view of the number; re-check the `error.code` on the refusal against [Compliance send-gate error codes](/compliance/troubleshooting-compliance-error-codes). Two adjacent responses are worth knowing: * `403 RND_SCRUB_NOT_ENABLED` on the lookup means the scrub flag is off for your organization. While it is off, sends are not scrubbed and this page's 422 cannot originate from the RND gate. * `409` when enabling the flag means no RND snapshot is configured for the deployment yet; until a feed is synced every verdict is `no_data`. See [RND scrubbing](/compliance/rnd-scrub). *** ## 4. Fix paths **A. Remove or re-verify the contact.** If the number is genuinely lost to you, suppress or remove the contact before the next campaign run; a recycled number is a suppression candidate, not a retry candidate. If the person still owns the number, re-verify ownership with them directly (a confirmation send on an unaffected channel, a double-opt-in handshake, or an out-of-band check) and keep the evidence. **B. Refresh the consent evidence.** Record the freshly confirmed grant in your consent ledger (Consent API or the managed double-opt-in flow). The gate evaluates the latest live grant for the contact and channel; once the recorded consent date post-dates `last_disconnect_date`, the lookup returns `status: "no"` and sends resume without any settings change. **C. Adjust your RND posture.** The scrub is a tenant toggle: Settings → Compliance, the FCC Reassigned Numbers (RND) scrubbing section, or `PUT /api/v1/compliance/rnd/settings` for owner/admin. Narrowing or disabling the scrub stops the refusals immediately (within the settings cache window, about a minute) — and moves the reassigned-number risk back onto your organization, which is exactly the trade the toggle exists to let you make. Every change to the flag writes an audit row, so the posture decision and its timestamp are provable in a review. On fail-open versus fail-closed: against a **confirmed** post-consent disconnect the gate fails closed — the send is refused. Against an **unevaluable** check (a feed or lookup error mid-send) the gate fails open and the send proceeds, because the scrub is an additive protection your organization layered on; an outage in it must not black-hole your traffic. Disabling the toggle is not the fail-open path — it removes the protection entirely, deliberately and on the audit record. *** ## 5. What never works: blind retries Resending the same payload returns the same 422. The inputs to the decision are your consent ledger and the RND record; neither changes between attempts, so there is nothing for a retry to wait out. This is not a rate limit, not a carrier congestion error, and it carries no retry-after window. Blind retries burn send budget, accumulate blocked rows in campaign views, and add audit noise without moving the verdict. Change the data (fix paths A or B) or the posture (fix path C) first; then send once and confirm the lookup verdict flipped before resuming the campaign. *** ## 6. Escalation bundle If the lookup returns `status: "yes"` against a consent date you can prove post-dates the disconnect, or a refusal persists past the settings cache window after a posture change, open a support ticket carrying: * The HTTP status and `error.code` from the refusal. * `meta.request_id` from the refusal envelope. * The destination as recorded on your side plus its redacted form (`details.to`, the MSISDN hash as it appears in your audit row) so the row can be correlated without resending full numbers. * The consent date the lookup was given and the `last_disconnect_date` it returned. That packet lets support replay the verdict without asking you for anything else. *** ## Cross-references * [RND scrubbing](/compliance/rnd-scrub) — the tenant-owned control: opt-in flag, defaults, and the audit trail it writes. * [RND safe-harbor preflight](/guides/rnd-safe-harbor-preflight) — using the lookup before campaigns, verdict by verdict. * [Glossary: Reassigned Numbers Database (RND)](/reference/glossary) — the FCC database and the reassignment risk it records. * [Glossary: Safe Harbor](/reference/glossary) — what the 47 CFR § 64.1200(m) protection covers and when it applies. * [Compliance FAQ](/compliance/faq) — tenant-owned posture questions, answered. * [Messaging pre-send gates](/troubleshooting/messaging-pre-send-gates) — routing a rejected send to the gate that fired. * [Verify OTP refusals](/troubleshooting/verify-otp) — the sibling `VERIFY_RND_REASSIGNED` guard on one-time-code sends. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.