Skip to main content

​
Batch DNC Pre-Flight Scrubbing

A pre-flight scrub answers one question before a campaign leaves the building: which numbers on this list would the send path’s Do-Not-Call gate block anyway? Run it on a cold list or a campaign audience, remove the flagged numbers, and only then launch. Orbit gives you two reads of the same DNC chain the send path enforces:
  • GET /compliance/dnc/check — one number at a time.
  • POST /compliance/dnc/scrub — a batch of up to 500 numbers per request, returning a per-number verdict plus summary counts.
The batch endpoint is what you want before a dialer or SMS campaign. This guide covers the full workflow: why pre-flight is worth the trouble, how the org gate works, how to run the scrub, and how to handle what comes back. For sources, feed wiring, and freshness fields, see DNC Scrubbing; for the send-time gates, see Send Gates. All endpoints below are rooted at https://api.orbit.devotel.io/api/v1/compliance.
This page describes Orbit’s platform 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.

​
Why pre-flight

DNC obligations are your responsibility as the sender, and the exposure is per call. In the US, dialing or texting a number on the FTC National Registry in violation of the Telemarketing Sales Rule is a per-call violation under 16 CFR § 310.4(b)(1)(iii)(B), with civil penalties in the tens of thousands of dollars per violating call. State registries and the TCR Universal Opt-Out list layer on top of the federal register — a federal-only scrub is not complete for US traffic. Outside the US, equivalent national registers apply: UK TPS/CTPS, Australia’s Do Not Call Register, India’s NDNC. The send path already blocks numbers that fail the chain, so a pre-flight scrub is not about whether blocked numbers go out — they won’t. It is about three practical things:
  1. You decide what to do with flagged numbers. A blocked send is a dropped message; a pre-flight verdict is a list you can route to suppression, remove from a segment, or review for consent before the campaign launches.
  2. You find out before launch, not after. A campaign that drops 40% of its audience at the send gate is a wasted launch and a confused reporting dashboard.
  3. You get a defensible record. Every scrub is audit-logged with aggregate counts, so a compliance review can show the pre-flight ran before the campaign went out.

​
The two read surfaces

Single number — GET /compliance/dnc/check. One E.164 number per request, rate-limited as a standard authenticated read (120 requests per minute per organization). Use it for ad-hoc lookups — an operator checking a single contact before a manual dial.
Batch — POST /compliance/dnc/scrub. Up to 500 numbers per request (duplicates are de-duplicated before scrubbing), rate-limited to 10 requests per minute per organization. Page larger audiences in 500-number chunks. That rate combination is sized so a mid-size campaign pre-flight never trips it; a script hammering the endpoint in a tight loop will hit HTTP 429 instead of a verdict.
Both endpoints accept an optional country parameter (ISO 3166-1 alpha-2, e.g. GB, AU, IN) that scopes the international national-registry lookup to one jurisdiction — a UK campaign is never flagged on an unrelated country’s record. Every per-number result carries the same shape:
The source tells you which layer flagged the number: jurisdictions lists every matching origin, so a number on both the federal registry and a state registry surfaces both. Prioritize by source: registry hits (federal_dnc, state_dnc, tcr, intl_dnc) are registry obligations — remove them from the audience. A suppression hit is your own recipient telling you to stop — it also belongs on your suppression list if it is not there already (see below).

​
The acknowledgment gate, in order

Both DNC endpoints are gated the same way. The gate resolves in this order — first true term wins:
  1. A platform feed is synced. Once Orbit has ingested a US federal/state/TCR snapshot or an international national-registry snapshot, the endpoints serve directly (federal_feeds_synced: true / intl_feeds_synced: true on every response). The gate is retired — no org action needed, ever again for that feed class.
  2. Your organization opted in. While no feed is synced, the endpoints are held behind your organization’s Do-Not-Call opt-in (the dnc_sync_enabled setting in your organization’s compliance settings — it is listed, with its default, on the posture map). The default is off.
Until one of those is true, every call to either endpoint returns HTTP 403:
The acknowledgment you are making by opting in: while no platform feed is synced, Orbit is not scrubbing against the federal register for you — so a number only on the FTC list reads back as on_dnc: false. The opt-in does not weaken any enforcement: your own DNC, suppression, and consent opt-out enforcement on outbound send paths runs regardless. One flip enables both endpoints.
Always read federal_feeds_synced and intl_feeds_synced on every response. They distinguish “the number is clear” from “the number is clear and a registry scrub backed that answer.” A clear verdict with federal_feeds_synced: false only means your own lists, suppression, consent, and the platform list did not flag the number.
Checking without running a check. GET /compliance/dnc/availability reports the gate state without scrubbing anything — the dashboard’s list-scrub card uses it to grey out or enable the scrub action up front:
available is the exact three-term gate above. When it is false, the per-org opt-in is the only self-service remedy.

​
Campaign-run workflow

Put the scrub between building the audience and launching the campaign:
  1. Build your segment with the audiences/CDP tools as usual.
  2. Check the gate — GET /compliance/dnc/availability. If available is false, enable the org opt-in (above) first.
  3. Scrub the segment. Page the audience into 500-number chunks and POST each chunk to /compliance/dnc/scrub.
  4. Split on the verdicts. Route every on_dnc: true row out of the send audience:
    • Registry sources (federal_dnc, state_dnc, tcr, intl_dnc) — remove the number from the campaign. Do not attempt to send.
    • suppression — add the number to your suppression list (or move it across contacts lists) so future audiences exclude it up front; see Opt-Out & Suppression Lists.
  5. Launch against the scrubbed audience — see Outbound dialer campaigns and Campaign end-to-end.
  6. Re-scrub stale audiences. National registries update on a business-day cadence and recipients opt out continuously, so re-run the scrub before each send for an audience you have held for more than a couple of days. The verdict you ran at audience-build time ages out as registries and consent records move.
The scrub never blocks what you keep: it is read-only. The gate that prevents a violating send is the send path, which re-checks the same chain at dispatch. The pre-flight is how you stop feeding the send path numbers it will only drop.

​
How it interacts with suppression and the preference center

The DNC chain treats registry obligations and your own suppression layer as one answer, but the source field keeps them apart:
  • Registry sources (federal_dnc, state_dnc, tcr, intl_dnc) come from synced national-register data. You manage that by keeping your audiences away from flagged numbers — you cannot remove someone from the FTC registry.
  • suppression is the recipient’s own signal reaching you: a STOP reply, a contact flagged DNC, an entry on a DNC or suppression list, a recorded consent opt-out, or a preference-center choice. These you can remedy — a recipient who opts back in through the preference center reverses the opt-out, and their number reads back clear on the next scrub.
Feedback loop worth building: when a scrub flags a number on source: "suppression" that you did not expect, check the contact’s consent record before you keep suppressing them — and when a recipient re-consents, re-scrub the segment before relying on the older verdict. See Opt-Out & Suppression Lists and Consent Management.

​
Troubleshooting

HTTP 403 DNC_SYNC_NOT_ENABLED on every call. The gate (above) is closed for your organization: no platform feed is synced for the class you are querying and your org opt-in is off. Enable the Do-Not-Call opt-in in your organization’s compliance settings and retry. Confirm the state with GET /compliance/dnc/availability — if available is still false after you flipped the setting, check you saved the organization settings change. Everything reads back clear — but you suspect that is wrong. Check federal_feeds_synced and intl_feeds_synced on the response. If both are false, no registry scrub backed the verdicts: a number only on the FTC register (or a UK/AU/IN register) reads back as on_dnc: false until the platform syncs the matching feed. The scrub is still telling you your own suppression story; it is not telling you the registries’ story. Do not treat clear verdicts as a federal safe harbor until the matching feed flag is true. HTTP 429 on bulk scrubs. The batch endpoint allows 10 requests per minute per organization. You are paging too aggressively — back off to one chunk every ~6 seconds, or chunk at the full 500 numbers per request so fewer requests carry the same audience. A 429 never consumes a request’s verdicts: retry the same chunk after the window resets. Numbers you removed get flagged again on the next scrub. Expected — the verdict describes the number’s registry state, not your list-building. Route repeated suppression hits onto your suppression list once, and let segment membership keep them out instead of re-discovering them each campaign.
See also: