Skip to main content

​
Compliance FAQ: sends, calls, and registration gates

This is the routing layer for compliance questions: a support reply, a first-time tenant setup, a “which gate fired?” lookup. Each answer is one to three sentences ending in a deeplink to the page that owns the topic — read this page to route the question, read the linked page before you act on it. Nothing here is a claim source; the linked page is always authoritative. For the mental model behind the routing table — which gates fail open, which fail closed, and who owns each control — read the Compliance Posture FAQ and the posture map.
This page describes Orbit’s platform controls. It is not legal advice. Which laws apply to your traffic, and what posture is adequate, depends on your jurisdiction, your recipients, and what you send. Confirm with qualified counsel.

​
10DLC & toll-free verification

​
My 10DLC campaign is pending. Can I send?

No. US long-code A2P traffic is fail-closed: sends are blocked until the campaign is approved by the carriers. Brand and campaign review typically takes 1–5 business days, and per-carrier statuses are tracked separately. See the full lifecycle on 10DLC registration and the parallel toll-free verification track for TF numbers.

​
Is my 10DLC campaign approval guaranteed by Orbit?

No — carriers approve; Orbit submits. Orbit registers your brand and campaign with the carriers on your behalf, but the approval decision is theirs, not the platform’s. 10DLC registration maps the carrier-side status poll — top-level PENDING / APPROVED / FAILED, plus the per-carrier mnoStatuses map.

​
How do I estimate my 10DLC throughput before registering?

Run the free 10DLC throughput & cost calculator — it estimates the T-Mobile and AT&T per-day message ceilings from a TCR trust score, and the daily cost at that ceiling, before you file anything. The registration lifecycle itself is on 10DLC registration.

​
What is the difference between a brand rejection and a campaign rejection?

A brand rejection is about your identity payload (legal name, EIN, website); a campaign rejection is about the use-case description and message samples. Rejected content fixes mean re-submission, while a low vetting score calls for a re-vet — the remedy differs, so decode the rejection code first on 10DLC rejections, re-vetting, and the post-approval lifecycle.

​
Sender ID & country requirements

​
My sender-ID was approved — why did the send still 422?

Approval means the registration itself landed; the send then still runs every other gate in the chain — quiet hours, DNC at send time, the HIPAA BAA backstop, and the per-country regional gates. Read the error code to see which one fired: the pre-send gate inventory is on Send Gates, and the per-code walkthrough is on troubleshooting: compliance send-gate error codes.

​
Why is my sender-ID stuck at pending, and what can I do besides wait?

Approval comes from the carrier or regulator, not the platform — Orbit files the packet, and the reviewer moves the status. For a rejected row the recourse is a re-submission: read the reviewer notes, fix the cited gap, and re-file on Sender-ID Registration; the re-submission choreography for pending / rejected rows (numbers and sender IDs alike) is on troubleshooting: pending numbers and Sender IDs.

​
Which countries require sender pre-registration?

Run GET /api/v1/compliance/country-requirements: the registration field on each country entry reads none, recommended, or required, and where it reads required you must have an approved Sender-ID entry before A2P SMS delivers. The per-entry workflow (pending → approved, or rejected with a reason) is on Sender-ID Registration.

​
Why did the sender-ID gate reject my send to a required-destination country?

The destination reads required in the country matrix, and your alphabetic sender has no approved registration row there — until it is approved, every send to that destination stops at the gate with a 422. Check which markets demand it on the Sender-ID country matrix, then file the registration on Sender-ID Registration.

​
I got SENDER_ID_NOT_REGISTERED on a send. What does it mean?

The from value is a custom alphanumeric sender ID with no registration row on your account — this gate is fail-closed. Register it under Settings → Sender IDs, or send with the platform default sender or one of your phone numbers. The full diagnosis (including SENDER_ID_NOT_APPROVED and the transient SENDER_ID_CHECK_UNAVAILABLE) is on Troubleshooting: SENDER_ID_NOT_REGISTERED.

​
Registration gate routing

​
My destination requires a second 10DLC campaign — do I re-upload everything?

No. File a second sms_10dlc_campaign_us profile under the same approved brand — the document library is tenant-wide, so the same doc_… id backs both campaigns and any other packet that takes the same role. Which doc_… ids carry over, and the two use cases that register separately, are on 10DLC brand & campaign profiles → §4.

​
A state law (e.g. Florida’s 8 PM close) blocks my send inside the federal window — is that a violation of the platform?

No — that is a state overlay winning over the federal rail, on a most-restrictive-wins rule, not a platform defect. Check which window applies before you schedule with GET /compliance/quiet-hours/preview: its reason enum and the next_allowed_at interpretation are on Quiet-hours preview → §3. The overlay map itself is on US state calling windows.

​
My 10DLC campaign is approved, but a stricter state window still blocks calls at 8 PM — which gate is that?

The state overlay, not 10DLC. Campaign approval clears the registration gate; the send then still runs the time gates, and a state close (Florida, Mississippi, and the rest) sits on top of the federal 8 AM–9 PM window on the same most-restrictive-wins rule. The overlay map is on US state calling windows; the federal rail it stacks on is on The TCPA federal voice guard.

​
My toll-free number is approved but DLT-India is pending — which gate fires first for India traffic?

Registration order does not sequence the gates — India traffic runs against the compliance profile for the destination, so a pending DLT row is checked per send regardless of what other registrations already cleared. The India gate depends on the profile being active, not on which registration you finished first. Decode the MESSAGING_IN_DLT_* family on troubleshooting: compliance send-gate error codes; the DLT artifacts themselves (Principal Entity → Headers → templates → consent) are on DLT India.

​
My Brazil sender is re-flagged by LGPD for a duplicated opt-in — where do I start?

Check the consent ledger — Brazil enforcement on Orbit is the consent ledger, the DSAR/erasure surface, and tenant-configured quiet hours, so a duplicated opt-in flag means the ledger, not the sender registration, disagrees with your list. The lawful bases and the Brazil FAQ are on the LGPD page.

​
My WhatsApp opt-out keyword is seeded on SMS but not WABA — is this a bug?

No — channel scope is the diagnostic. The shipped seed rules are scoped to the sms channel; a rule only fires on the channel it is stored with, so WABA opt-outs need a rule added on the whatsapp channel. The suppression that any matched rule writes, though, is scoped to all, so a STOP received on one channel suppresses the number across channels. Scope semantics and propagation are on the opt-out keyword alias table.

​
Reachability screening

​
How do I check whether a number can even receive SMS before I buy it?

Run the free carrier & line-type lookup — it classifies the number from the numbering plan (mobile, fixed line, toll-free, VoIP, premium rate, and the rest) and returns a plain-yes/no verdict per channel, so you skip line types that cannot take SMS before the number costs you anything. How to read a depends verdict and the per-line-type reachability table are on Line type and reachability classification.

​
How do I check whether a destination can receive RCS before launch?

Run the free RCS reach checker — it estimates whether a number can receive RCS from published country coverage and the line type, so a fixed-line destination (a definitive no for SMS and RCS alike) never enters a launch list. The onboarding sequence it feeds is on RCS onboarding.

​
STIR/SHAKEN

​
Why is my outbound call signed at attestation level C?

C means the platform cannot verify ownership of the calling number, so it attests “the gateway can’t tell where this call originated” — which exposes the call to spam-likely treatment downstream. Register a delegate certificate to lift covered numbers from C to B (partial). Details on Attestation posture and Troubleshooting: attestation stuck at C.

​
Should I register a delegate certificate?

Yes, if you bring your own verified numbers (BYON): registering an ATIS-1000092 delegate certificate lifts the numbers it covers from C to B. A self-registered certificate can only ever reach partial (B) — full attestation (A) on a number you did not port into Orbit would be spoofing, and the registry will never mint that. The registry lives at /compliance/attestation/delegate-certs; see Attestation posture.

​
Send-gate error codes — quick routing

For the code today, route to one entry on the troubleshooting page for send-gate error codes:

​
Which code family tells me a KYC/profile gate fired versus a spam keyword hit?

A profile gate carries its status in the code name — a 422 COMPLIANCE_PROFILE_REQUIRED or …_NOT_APPROVED fires before dispatch when a regulated surface demands an approved compliance profile. A keyword hit carries the scanner’s verdict in the payload instead — the pre-send scanner refuses with 422 POLICY_VIOLATION and names the matched rule in details, so the family is read off the code prefix first and the details map second. Both decode on troubleshooting: compliance send-gate error codes; the scanner’s rule taxonomy lives on Spam keywords and content screening.

​
When do I file a new compliance profile for a country change?

A feed refreshing the country-rules table never rewrites your profile — updates land in the structural columns only, so when a destination raises its registration level (say, recommended → required) the new rule applies to existing traffic and you file against the new rule, not a protected profile you were carrying. The current per-country level is on GET /api/v1/compliance/country-requirements; what a refresh can and cannot change is on Country rules auto-refresh feeds, and the profile and KYC-document lifecycle the filing goes through is on KYC documents & the compliance-profile lifecycle. The page maps each code to root cause, tenant-owned control, a re-check curl, and the escalation path — tickets close on it.

​
TCPA & quiet hours

​
What is the one gate I cannot turn off?

The US TCPA federal voice dialing window: campaign and dialer voice to US (+1) recipients outside 8 AM–9 PM recipient-local is hard-blocked with 422 TCPA_FEDERAL_DIALING_WINDOW_BLOCKED — no tenant toggle, no per-organization bypass, and no fail-open on a timezone-unresolved recipient. The 500–500–1,500 per-call statutory penalty is not the tenant’s to waive. Read The TCPA federal voice guard; the stricter state overlays on top of it are on US state calling windows.

​
Can a tenant lift the emergency-call block?

No. Emergency numbers (911 / 112 / 999 / 000) always route on Orbit, and no tenant gate can block them — the same stance as the federal TCPA window. Details and the address-registration duty for emergency routing are on Emergency calling.

​
How do state mini-TCPA overlays interact with the federal window?

Stricter state overlays — Florida’s Sunday ban, Mississippi’s 7:30 PM close, and the Oklahoma / Louisiana / Alabama / West Virginia windows — sit on top of the federal rail on a most-restrictive-wins rule and, like the federal window, are not a tenant knob. The overlay map is on US state calling windows; the blocked-call codes (TCPA_STATE_DIALING_WINDOW_BLOCKED, TCPA_DIALING_WINDOW_BLOCKED, TCPA_TIMEZONE_UNKNOWN) are decoded on Troubleshooting: state mini-TCPA blocked calls.

​
Where can I check whether a US send is inside the federal window right now, without making a call?

Run the free TCPA quiet-hours checker — it reports whether the current time falls inside the federal 8 AM–9 PM telemarketing window for any US timezone, in plain language, without placing a test call. The hard block behind that window is documented on The TCPA federal voice guard.

​
Which TCPA window is blocking my US voice send — the tenant gate or the federal guard?

Read the error code — FEDERAL in the name is the answer. 422 TCPA_FEDERAL_DIALING_WINDOW_BLOCKED is the platform’s hard 8 AM–9 PM recipient-local guard: no setting on your account widens it, so the only recovery is to schedule at the next_allowed_at timestamp in the error payload. 422 TCPA_DIALING_WINDOW_BLOCKED is your own opt-in voice quiet-hours gate — tighten, loosen, or disable it under Settings → Quiet hours. The full split, including why the federal guard fails closed on an unresolvable timezone where every tenant gate fails open, is on The TCPA federal voice guard.

​
Do voice and SMS resolve quiet hours the same way through a DST change?

Yes — every channel’s quiet-hours gate reads the recipient-local clock, so a DST transition shifts the window boundary in step for voice and SMS alike rather than drifting an hour against UTC. Blocked sends return an absolute, DST-safe next_allowed_at UTC instant the send can be re-armed at directly; the voice gates return the same field, so you schedule over the transition instead of polling. Preview the resolved window per destination before a rollout with GET /compliance/quiet-hours/preview — the posture question it answers (“would this send be held, and until when?”) is walked through on the posture map, and the window semantics on Send Gates.
The unknown consent state is resolved by your org’s posture knobs, not by the ledger — and both default to the conservative side. Marketing sends to an unknown-consent contact refuse by default (unknown_marketing_policy), while CDP destination fanout permits a missing consent row by default (consent_default_policy: permit_on_missing); both are owner-writable with an immutable before→after audit entry, and neither ever inverts an explicit opt-out. Policy values, scopes, and posture tables are on Consent Posture: The Unknown-Consent Policies.

​
Opt-out & suppression

​
Does a STOP on SMS also block voice calls?

By default, yes. A STOP keyword on a phone number records the opt-out with the all channel scope, which suppresses every channel reachable on that number — and the voice and dialer gates honour phone suppressions, so the number stops receiving calls too. Scope semantics (all vs a specific channel) and recovery are on Opt-Out & Suppression Lists.

​
I imported my opt-out CSV but a recipient still gets messages — why?

A scope mismatch. Every suppression row carries a per-row channel scope, and the send-time gate respects it exactly: a row imported with email scope gates email only — it does not suppress SMS to the same address, and sms-scoped rows do not gate email. Check the scope column on the row you imported (POST /compliance/suppression-list/import returns per-row results including the resolved scope) and re-import with the channel you actually need gated, or all. Full diagnosis — find the mistaken row across a large import, re-import with corrected scope, and rule out the other gates — is on Troubleshooting: suppression scope mismatch; scope semantics are on Opt-Out & Suppression Lists.
Use the CSV import (POST /compliance/suppression-list/import) when you are backfilling a legacy opt-out list — it returns per-row results with intra-file deduplication. Use the Consent API for live per-event consent and revocation. Both feed the same suppression chain, so a suppressed address is dropped pre-dispatch regardless of entry point. The end-to-end task guide — decision table, worked CSV row set, grant/revoke pair, and scope discipline — is on Choose your suppression entry point; see Opt-Out & Suppression Lists. If your DNC pre-flight check returns 403 DNC_SYNC_NOT_ENABLED, the fix is on the DNC check gated troubleshooting page.
Yes — the three entry points are mirrors over a single suppression ledger, so every send gate sees the same picture regardless of where the opt-out arrived. Bulk CSV import backfills legacy lists with per-row results and intra-file dedup; the Consent API records live per-event grants and revocations for your own flows; the Preference Center gives recipients a signed per-contact self-service link that writes the same revocation. All three honour per-row channel scope (all vs a specific channel) — a mismatch there is the one case where mirrors disagree at the gate. Choosing and wiring the three inputs is taught end to end on Choose your suppression entry point; scope semantics and recovery are on Opt-Out & Suppression Lists; the Preference Center endpoints are on Send Gates → Preference center.

​
Does the preference centre feed the same suppression ledger as STOP?

Yes — a preference-centre opt-out and an inbound STOP keyword both write into the one suppression ledger, so every send gate reads a single picture regardless of entry point, and an opt-out recorded on either path suppresses the same channels at send time. The ledger itself is on Opt-Out & Suppression Lists; the preference-centre endpoints and link flow are on Send Gates → Preference center.

​
I uploaded a campaign last night and queued 40,000 sends. A recipient replied STOP this morning — will the queued send still fire?

The short answer: no — the queued send for that recipient is dropped. Suppression is checked at dispatch, not at queue time. Every send gate reads the suppression ledger before dispatch regardless of campaign, contact import, or API call (Opt-Out & Suppression Lists), and a STOP that matches the alias vocabulary writes its entry as part of handling the inbound reply — the next send attempt after the entry exists is blocked (TCPA Reasonable Revocation (2025), Section 4). With the send queued last night and the STOP recorded this morning, the entry precedes the dispatch attempt, so that recipient resolves to status: "skipped" in the campaign report while the rest of the batch goes out. When the answer is different. That is the alias path. A revocation outside the alias vocabulary — free text, a request spoken on a call, an email — runs through your review pass, and its propagation lag is the one Section 4 names: zero for the alias path, up to 10 business days on the review pass, bounded by the internal SLA you set. On that path a queued send fires if dispatch runs before your review writes the entry — which is why the order watches your review clock, not the platform’s. What a STOP does not undo. The gate reads the ledger before dispatch; it does not retract what is already with the carrier. An SMS already dispatched or a call already ringing when the STOP lands is not recalled — the entry suppresses the next send. That is the honest edge of suppression: a pre-dispatch fence, not a recall. Where verified. Pull the Settings → Audit log row for the STOP receipt: its timestamp shows the entry was recorded before the dispatch window. Then export the ledger (consent & suppression export) as downstream proof — an active row whose suppressed_at predates the dispatch attempt is the evidence that the fence was up when the send was evaluated. Compliance position. On the alias path you comply with the 10-business-day window by a margin of days, and the audit row plus ledger export is the evidence pack for that claim. No platform hard gate is asserted here — this is tenant evidence: a timestamped revocation, a recorded entry, and a queued send dropped at the gate. Which window governs your traffic is a question for your counsel.

​
The 10-business-day TCPA window: measured from the revocation or from the last send?

From the revocation. The April 2025 revocation rule (47 CFR § 64.1200(a)(10)) requires honoring a revocation “as soon as practicable, and in any event within 10 business days” — the clock starts when the recipient communicates the revocation, not when you last attempted a send. A suppressed send attempt inside the window is evidence the gate read the ledger; it is not a new starting gun. A last-send clock would let every attempt restart the window, and the rule forecloses that reading. What Orbit records. On the alias path, the suppression ledger row carries suppressed_at — the instant the STOP entry took effect, written as part of handling the inbound reply — and the consent ledger carries the matching revoked_at on the consent row. On the review path, the timestamp you write through the Consent API (POST /api/v1/compliance/consent with opt_in: false) is the moment your team recorded the request, so note the moment the consumer communicated it in notes and keep the conversation history beside it. Both ledgers export on Consent & Suppression Export. Proving it in the export. Bound GET /compliance/suppression-list/export around the revocation and quote the row next to the blocked attempt:
The row shows the entry took effect at 14:22:11Z, the same second the STOP arrived. A send attempt one second later (2026-10-13T14:22:12Z) returns 422 RECIPIENT_OPTED_OUT; in a campaign report the same recipient resolves to status: "skipped". The audit-log timestamp for the STOP, this row, and the refused attempt form the evidence pack: revocation communicated, entry recorded, next send blocked. What the tenant still owns. The review-path rows. A revocation that arrives outside the alias vocabulary — a voicemail, a support email, a free-text reply — produces no ledger row until a human records it, and finishing that reconciliation inside 10 business days is your obligation, not the platform’s. The internal SLA, named owner, and weekly reconciliation that keep the review path inside the window are on TCPA Reasonable Revocation (2025), Section 4. The neighboring question. This entry answers when must sends stop; the entry above answers does a send already queued fire once a STOP lands. The 10-business-day frame is what separates the two: the queued-send question is about entry-versus-dispatch order on the day, while the window question is about the distance between the revocation and your last attempt.

​
DSAR clocks

​
What deadline applies to a GDPR versus a CCPA DSAR?

GDPR gives you 30 days; CCPA/CPRA gives you 45 — and the deadline is yours, not the platform’s. The intake, verification, and fulfilment workflow per regulation is on the DSAR page.

​
DNC & RND scrubbing

​
Why is DNC off by default?

Because DNC is a list-hygiene control, and list-hygiene controls fail open by design: you opt in with dnc_sync_enabled. The important caveat — on the hosted platform a clear verdict only counts as federal safe-harbor when federal_feeds_synced: true; until the federal feed is synced, a number listed only on the FTC register reads back clear. Sources, freshness, and the check endpoint are on DNC Scrubbing; the gate error itself is on Troubleshooting: DNC_SYNC_NOT_ENABLED.

​
BAA & HIPAA

​
Is my BAA on file?

Read GET /api/v1/compliance/baa — any state other than executed means no current agreement, and HIPAA mode will not enable until that read. The full state machine, the e-sign flow, and each endpoint’s role gate live on the BAA page.

​
I signed the BAA — why is HIPAA mode still off?

The signed BAA is a prerequisite, not a switch: HIPAA mode is an owner-writable toggle that only enables once GET /api/v1/compliance/baa reads executed and in-term — until you flip it, the rest of the control set stays off. The BAA state machine and the e-sign flow are on the BAA page; the execute-order from BAA through the mode toggle and the controls that follow is on the HIPAA posture guide.

​
I already have a HIPAA checklist tool walkthrough — why is my HIPAA mode still blocked?

Two different layers. The HIPAA/BAA readiness checklist is a self-assessment — it walks the five tenant-owned HIPAA posture steps in your browser and scores what you mark done. The HIPAA-mode gate is the live BAA gate: it reads the actual executed Business Associate Agreement on your account and refuses to enable until GET /api/v1/compliance/baa returns executed. A checked box in the tool posts nothing back, so list the final step there, then complete the e-sign flow. The gate details live on the BAA page; the recovery path is on Troubleshooting: HIPAA enable blocked (403).

​
Why did my send throw HIPAA_BAA_REQUIRED?

HIPAA mode is enabled for your organization and the send’s audience or content matched PHI — the mode refuses PHI-bearing sends with 422 HIPAA_BAA_REQUIRED until a Business Associate Agreement is executed, and HIPAA mode itself will not enable until then. The gate list is on Send Gates; the two recovery paths are Troubleshooting: HIPAA enable blocked (403) and Troubleshooting: HIPAA_BAA_REQUIRED (422).

​
Incidents & fraud review

​
How do I halt every outbound send in one move?

Reach for your organization’s emergency stop — one switch that halts every outbound dispatch path (SMS, MMS, voice origination, dialer campaign activation) until you lift it, with only owner/admin roles allowed to flip it. Blocked sends are rejected with 403 ORG_COMPLIANCE_EMERGENCY_STOP before provider dispatch, and a failed status lookup fails open so a transient read error cannot black-hole outbound traffic. The switch recipe — total-recall semantics and the recovery path — is on Emergency Stop.

​
What triage sequence should I run on a new fraud alert?

Work the four-step loop: list the open reviews, open the full row, acknowledge it to claim it, then dismiss it as a false positive or accepted risk. The step-by-step walk, the valid status transitions, and what’s locked when a row reads escalated are on Fraud Review Triage.

​
The one platform-mandated control

​
Is there any compliance control the platform owns outright?

Exactly one: the US TCPA federal voice dialing window described in the TCPA section above. Every other compliance control — quiet hours, DNC, RND, STIR/SHAKEN floors, HIPAA mode, DSAR, KYC gates, sender-ID registration — is tenant-owned, ships off or open, and fails open on unresolvable input. The full asymmetry list is on the posture map, and the guard itself is on the TCPA federal voice guard.