Quick answer: Numbering carriers publish a daily feed of subscriber numbers they deactivated or disconnected — the subscriber cancelled, ported away, or had the number reclaimed. Devotel Orbit's carrier deactivation scrub checks your lists against that feed so a churned number is pulled before it burns A2P throughput or delivers a marketing text — or worse, a one-time code — to whoever holds the number now. It ships off by default per organization, and one tenant toggle turns on the API surface and the automatic pre-send guards together.
The mechanics live in the docs. This post is the editorial version: what the feed contains, why your existing scrub stack still misses churned numbers, where the exposure bites, and where Orbit enforces the verdict.
Three scrubs, three different questions
Senders who already scrub their lists often assume they have this covered. They usually have two of three layers:
- The DNC scrub answers "did the person ask to stop?" — the
federal, state, TCR, and international registries, plus your own suppression list and consent ledger.
- The RND check answers the TCPA safe-harbor question "was this
number permanently disconnected after my consent date?" — the FCC Reassigned Numbers Database, consulted per number before dialing or texting.
- The deactivation scrub answers "did the carrier deactivate
this number since I last saw it valid?" — a carrier disconnect feed, not a registry.
The three answer orthogonal questions. A number comes back clear of every DNC registry and there is still no answer to whether the carrier still binds it to your recipient. "Not on the DNC list" is a fact about the person's relationship with telemarketing — it was never a fact about the number's binding. Scrubbing "we ran it against the registry" and "we have a line of sight to carrier churn" are different claims, and only one of them stands up the morning a reactivation campaign launches against a list that has not been touched in two quarters.
The count on the first full-list run is usually small — a single-digit percentage of contacts whose carrier relationship changed since the list was built. Small enough to keep skipping, costly enough that each hit is exactly the message you did not want a stranger to read.
What a disconnect feed actually publishes
This is not a registry of complaints, and it is not a "this number is invalid" verdict. Carriers publish daily which subscriber numbers they deactivated: the line was cancelled, it was ported away and lapsed into cancellation, or the carrier reclaimed it for reassignment. Each record carries a deactivation date, which is what makes the scrub able to compare that date against your last-valid date rather than force a blanket verdict on every historical record.
Two flow-on facts matter operationally. First, deactivated numbers come back. Once deactivated, a number can be recycled to a new subscriber — which is where the legal exposure below comes from. Second, the three hypotheses a "clear" verdict can support are all safe: the check says "no disconnect seen so far," and a hygiene gate only ever scrubs a number the feed has positively flagged.
Where the TCPA exposure comes from
For US traffic, texting or calling a reassigned number after the carrier cleared it is wrong-recipient delivery, and that is a 47 U.S.C. § 227 (TCPA) exposure — the FCC has treated reassignment as a placed risk since the 2015 declaratory ruling, and post-Loper Bright reasoning has not made chatty re-engagement programs safer. Each text to a stranger who never consented to you is a putative violation with statutory damages per send, and TCPA plaintiffs' firms file on complaint data with a low barrier.
One-time codes are not the outlier case here — they are the worst one. An OTP landing on a reassigned number gives a stranger account access. Marketing texts are reputational; OTP delivery to the wrong handset is an account-takeover vector. Both come back through the same upstream cause: no carrier-churn layer in the pre-send chain.
To be plain about scope: the scrub is one control among several in a TCPA posture, not a claim that you are compliant for having run it. It closes the carrier-churn hole; consent capture, DNC registries, quiet hours, and the RND check each still do their own job. Read this post as the argument for adding the layer, not as a legal claim.
Where Orbit enforces the verdict
Opting in does more than unlock the endpoints: the same feed powers automatic pre-send guards, so enforcement does not depend on someone remembering to pre-flight.
- SMS and MMS. Before dispatch, the message pipeline looks up your
most-recent prior-express consent date for the recipient. A carrier deactivation on or after that date refuses the send with a 422 and a MESSAGING_NUMBER_DEACTIVATED code; a deactivation that predates your consent does not block a legitimately consented send. Campaign bulk-sends route through the same pipeline, so the guard holds under batch traffic.
- Voice and the dialer. The dialer evaluates the same verdict
before originating toward a NANP (+1) destination — the current carrier feed covers NANP numbers, so non-NANP destinations are skipped rather than mis-gated.
- Verify / OTP. A one-time code sent on a phone channel is refused
with VERIFY_NUMBER_DEACTIVATED whenever any deactivation record is on file. There is no consent ledger for a login code, so the guard uses a strict disconnect-presence model.
Every refusal writes an audit entry, so a compliance review can prove the guard fired instead of inferring it.
Two manual endpoints complement the automatic guards, both under /api/v1/compliance/deactivations: GET .../check returns a per-number verdict (deactivated / active / no_data), and POST .../scrub pre-flights up to 1,000 numbers per request before a campaign. Both accept a last_seen date — when you last validated the subscriber relationship — so a deactivation that predates the current relationship does not scrub a legitimately re-verified number.
Turning it on
The scrub ships off by default per organization. Until you opt in, the check and scrub endpoints return 403 DEACTIVATION_SCRUB_NOT_ENABLED and the send-path guards skip. From the dashboard, open Settings → Compliance and flip the carrier deactivation scrub toggle; over the API, PUT /api/v1/compliance/deactivations/settings with { "enabled": true }. Any authenticated member can read the setting; only an org owner or admin can change it. One flip enables both the API surface and the pre-send guards; the write lands in the compliance audit log.
The fail-open caveat, read correctly
Orbit's scrub verdicts carry a feed_synced flag, and the warning it encodes is worth internalizing before you run your first campaign against the scrub:
> Until a carrier deactivation snapshot is synced, every verdict is > `no_data` and clear — for every number.
The guards are fail-open by design: a lookup error, a missing feed, or an unset opt-in declines to block, so this additive hygiene layer never black-holes a send. That posture is safe, but it changes what "passed the scrub" means. Two rules follow:
- A clear verdict means "no disconnect seen so far," never "safe."
The algorithm deliberately degrades to default-keep rather than claim a clean verdict it cannot back.
- A skipped scrub counts as scrubbed only if the feed had data.
Weigh feed_synced before relying on a pre-flight result.
On the SaaS platform the feed is synced centrally; on self-hosted deployments the operator configures the carrier snapshot.
Further reading for operators
The full reference — endpoint contracts, per-field verdict semantics, recovery procedure after a block, and the three-scrub comparison table against DNC and RND — is Carrier Deactivation (Churn) Scrub in the docs. The order in the send-time chain and the other tenant gates are in Send Gates, and the recovery branches for a VERIFY_NUMBER_DEACTIVATED refusal are in Troubleshooting Verify OTP.
Frequently asked questions
Does the scrub apply to international numbers?
The current carrier disconnect feed covers NANP (+1) numbers. For non-NANP destinations the voice and messaging guards skip rather than mis-gate, and a manual check returns no_data; the DNC and RND layers still apply wherever they have coverage.
Is scrubbing sufficient for TCPA compliance?
No. The scrub closes the carrier-churn hole in a pre-send chain — one control among several. Consent capture, DNC registries, quiet hours, suppression hygiene, and the RND check each still do their own job, and this post is not legal advice.
What happens if I turn it on mid-campaign?
Guards evaluate at send time per recipient, so the toggle takes effect for the next dispatch attempt; queued sends already resolved to a done or failed state are not retroactively blocked.
Can I pre-flight a whole list before a campaign?
Yes — POST /api/v1/compliance/deactivations/scrub accepts up to 1,000 numbers per request and returns per-number should_scrub verdicts with reasons, suitable for dropping rows from an audience before launching.