Skip to main content

​
Omnichannel fallback compliance matrix

Choosing a primary channel is not only a reach and cost decision. Each channel carries a different compliance burden, and a fallback chain only works when the next channel in the chain is one your tenant is actually permitted to use. This page consolidates the compliance comparison that otherwise lives scattered across Country Compliance Requirements, STIR/SHAKEN Attestation Posture, and Outbound send gating. Read it once before you assemble a fallback chain; then dive into the deep page for the one or two planes your traffic actually touches.
Every control described here is tenant-owned. Orbit carries the settings and enforces what you set; which laws apply to your traffic and what posture is adequate is your call. This page is not legal advice — the sole exception is the federal TCPA voice dialing window for US recipients, which is a platform guard you cannot toggle.

​
1. The three planes you weigh per channel

Before you pick a primary or fallback channel, weigh three independent planes. A channel can clear one plane and fail another — the matrix below scores each channel on all three.
  • Registration plane — what you must register before the first send: US 10DLC brand and campaign, DLT (India), per-country Sender-ID registration, toll-free verification, or nothing. Until registration clears, the channel is either blocked (fail-closed, as with Sender-ID countries) or degraded (unregistered 10DLC traffic gets filtered upstream).
  • Window plane — when you may send, recipient-local: the federal TCPA voice window plus state mini-TCPA overlays on US voice, or the per-channel quiet-hours windows you configure yourself everywhere else.
  • Consent plane — the opt-in regime the traffic must satisfy: TCPA opt-in for US SMS marketing, GDPR prior-consent in the EU, CAN-SPAM and CASL for email, Meta’s opt-in plus template rules on WhatsApp.
Registration is lead time, windows are a send-time gate, and consent is the posture you must be able to evidence. All three are your responsibility to set; Orbit enforces the configuration, it does not decide for you.

​
2. The per-channel matrix

One row per channel: the registration burden, the window constraints, the opt-in regime, and any attestation layer. The per-country rows behind the SMS column come from GET /api/v1/compliance/country-rules, which is the read-only reference the send-time gates consult — query it per market before you commit a channel plan.

​
3. The fallback decision table

A fallback hop is legal to configure only when the destination channel clears all three planes for that recipient. Run these checks in order; the first no stops the chain. Two rules hold on every hop:
  1. Consent is per channel. Opting into email does not opt the contact into SMS; a fallback hop re-runs the destination channel’s opt-out, suppression, and quiet-hours gates — the same chain documented in Outbound send gating.
  2. The voice window cannot be configured away. Any chain that ends in US voice is bounded by the federal TCPA window. Plan chains that degrade to SMS or email rather than assuming voice is always available.

​
4. Where each control lives

Per channel, per plane — the surface where you set the posture:
  • Quiet hours per channel — settings → quiet_hours.<channel>.enabled via PUT /api/v1/settings/general; the full gate order is on Outbound send gating and the window mechanics on Send Gates.
  • Opt-out and suppression — STOP keywords, the Consent API, and bulk import; scope decides breadth (all-scope entries gate voice too). Details on Opt-Out & Suppression Lists.
  • Sender registration — POST /api/v1/compliance/sender-id-registrations per country; the per-market rules it enforces are readable through GET /api/v1/compliance/country-rules.
  • Attestation target and reporting — Settings → Compliance → Attestation; fields and semantics on Attestation Posture.
  • DNC scrub — org setting dnc_sync_enabled, queried through GET /api/v1/compliance/dnc/check; DNC Scrubbing covers the fail-open posture.
The toggle map across all of these — defaults, fail-open versus fail-closed per surface — is the tenant compliance posture overview.

​
5. Two worked channel-selection examples

US mixed traffic — 10DLC SMS primary, owned-DID voice fallback. A tenant ships order-status notifications to US recipients and wants a voice fallback for “delivery exception” alerts. Primary is SMS on an approved 10DLC campaign; the fallback chain ends in voice from DIDs the tenant owns, so originations attest A and clear the branded-calling screen when enabled. Every hop into voice is still bounded by the federal window — an exception alert at 22:30 recipient-local holds until the window opens; the chain falls back to holding the SMS rather than dialing. Setup order: register the 10DLC brand and campaign first (lead time), then set per-channel quiet hours, then attach the owned DIDs and declare the attestation target. EU traffic — Sender-ID SMS, email with GDPR prior-consent. A tenant runs lifecycle notifications across France and Germany. SMS rides registered alphanumeric Sender IDs where the corridor recommends them (FR per the country-rules reference), email handles long-form drift (templates, invoices) under GDPR prior-consent evidenced through the Consent API. The fallback email→SMS hop only runs for contacts whose consent record carries the SMS channel — otherwise the hop is refused and the send waits for the email retry window. Registration lead time is days per Sender-ID country; the DNS identity (SPF/DKIM/DMARC) clears the same week, so email opens first and SMS joins as registrations land.

​
6. A worked fallback decision — US marketing, SMS primary → WhatsApp fallback

Walk one concrete scenario end to end. A tenant runs a US marketing program: SMS is the primary send, WhatsApp is the fallback the chain tries when the primary send cannot proceed. Which plane trips first differs per fallback leg — that is the point of weighing the matrix per channel instead of once per chain. Leg 1 — enter SMS. Resolve the destination with GET /api/v1/compliance/country-rules?channel=sms. For US corridors the row resolves registration: "none"; corridors that carry a recommended or required mark make their own fallback decision before the chain is built. The register read explicitly clears the SMS leg for US traffic — absence of a requirement is a resolution, not silence. The SMS leg then walks the ordered gate chain from Outbound send gating. Assume the recipient’s US number lives in a corridor where the sender profile cannot deliver, and the send cannot proceed on SMS. The matrix says the consent plane holds, so the hop is legal only if the remaining planes also clear. Leg 2 — check the WhatsApp hop. Meta opt-in and approved templates are the consent plane on WhatsApp. If the consent plane fails here, the hop stops — consent is per channel. If the consent plane clears, the window plane stays tenant-owned and the tenant’s per-channel quiet hours run as configured. The hop re-checks GET /api/v1/compliance/quiet-hours/preview?phone=<E.164>&channel=whatsapp against the tenant-quiet window. The enforcement point is the send-time gate on Send Gates; the preview endpoint tells you whether that gate would hold before the chain runs. The one plane that cannot shift is the federal TCPA voice window. That is why the chain degrades to WhatsApp rather than trying US voice: a voice-ended chain would sit on the platform guard no tenant can toggle. The matrix call: for US marketing, SMS primary with a WhatsApp fallback clears all three planes without touching the one plane you cannot control.

​
7. Reading the matrix with the country-rules register

The matrix scores channels in the abstract; whether a given country+channel corridor requires registration, and how the gate enforces it, comes from the register. The register is the same read-only reference the send-time gates consult. Query it per market before you commit a primary. For the US marketing scenario above, the SMS rows resolve explicitly; for an SMS corridor with a registration plane the matrix flags (the registration-required marks) the register returns the row that decides the fallback before the chain is built. Query a specific country+channel row:
The registration field resolves none, recommended, or required per row. A required row for an SMS corridor in France registers a Sender ID before first send — submit through POST /compliance/sender-id-registrations; the send-time gate for that country fails closed on unregistered traffic until approval lands. An SMS row with none means the matrix’s registration plane clears for that corridor on SMS alone; the fallback reasoning you run per hop (carried in the scenario above) operates only on the rows that actually require registration. Resolve the register per market once, and the worked decision walks only the corridors it has to.

​
See also