Skip to main content

​
Sender-ID pre-registration: the market-choosing matrix

The most expensive onboarding surprise is not a rejection — it is discovering after you have chosen a launch market that the destination blocks unregistered alphabetic Sender IDs outright. Until the registration clears, every send to that destination returns a 422 from the send gate, and some markets take weeks to approve. This page turns the flat Country Compliance Requirements reference into a choosing matrix: for each candidate market you read one registration value — none, recommended, or required — and plan from it. Read it before you pick markets, not at send time.
Registration is granted by the carrier or regulator in each country, not by Orbit — the values below tell you what to plan for, not a delivery guarantee. Coverage is enabled per tenant: a market listed here is not necessarily enabled on your account.

​
Read the matrix at choose-time, not send-time

The per-country rules are served by one endpoint — GET /api/v1/compliance/country-rules — the same read-only reference that backs Orbit’s send-time gates. Any authenticated user can call it. A brand integrating Orbit typically has a choose step in its own flow (“pick your launch countries”); that step should call the endpoint and surface the registration value per country, so a market that requires pre-registration shows its lead time before the brand commits to it.
Each row carries the country, the accepted sender types, and the registration level. Filter by region to narrow the scan (e.g. ?region=EU), and call it once per channel — sms, rcs, whatsapp, voice, email, viber — because the same country answers to a different regulator per channel.
The destination accepts a sender with no registration. You can start sending as soon as the country and channel are enabled on your account.
The send-time gate blocks all A2P traffic to this destination until a Sender-ID registration for the country reaches approved. Treat the approval lead time as part of your launch plan — weeks in some markets.

​
The five hardest markets to plan for

Read the live value from the endpoint — the table below is the current planning snapshot for the markets that surprise operators most, not a frozen copy you should code against. Two adjacent cases worth knowing:
  • India — registration is required, but the regime is TRAI DLT rather than a plain Sender-ID registration: headers, content templates, and a template id on every send. See DLT-India onboarding.
  • Dynamic-alpha markets (much of the EU, e.g. France) — registration: none or recommended: an alphabetic Sender ID works without pre-registration, but register it anyway where you can — unregistered dynamic alpha is the traffic carriers relabel first when filtering tightens.
For every other market, pull the value at choose-time: the registration field on the country row is the answer, and sender_rules on the same row carries the nuance (dynamic vs. pre-registered, name vs. ID, format).

​
In-row triage for required markets

Use this table to triage a required market in-row. Each row surfaces the three fields that most often block a launch: typical lead time, document class, and channel type. Each value is a pointer into the full country-requirements profile and the per-class windows in Sender-ID Registration lead times. Use it as a triage: if a candidate market is in the table, the window column is the number you build your launch date around. For markets absent from the table, the default window for alphanumeric pre-registration sender IDs is 1 day – 6 weeks, with the long end hitting most pre-registration markets in Africa, South Asia, South America, and the Middle East. Confirm the row’s registration value and sender_rules at choose-time on the endpoint before committing.

​
How the send gate enforces it

When a destination is required and the sender has no approved registration for that country, the send-time gate rejects the send with a 422 and a market-specific code — for example MESSAGING_SA_SENDER_NOT_REGISTERED or MESSAGING_BR_SENDER_NOT_REGISTERED. The gate only checks alphabetic senders; a numeric long code routes through carrier provisioning instead. See Send Gates for how gated sends behave and what the error payload carries. To clear the gate, submit the registration from Settings → Sender IDs or via the Sender-ID API, attach the KYC documents the market expects, and wait for approved. The documents themselves — proof of business, use-case description, brand authorization — live in your document library and are referenced by ID across registrations. See KYC Documents & the Compliance-Profile Lifecycle and Sender-ID Registration.

​
Example: an RCS/SMS choose flow

A brand choosing between RCS and SMS for a launch market should check both channels — they can disagree (SMS may be required while RCS is recommended, or vice versa):
Expected shape for the UAE over SMS:
Handle the decision in your choose UI:
  • required → show the market with a “registration needed” flag and an estimated lead time before you let the brand commit to it.
  • recommended → launchable, but queue the registration as a follow-up reliability task.
  • none → launchable immediately.
This is a lookup pattern, not a new endpoint: any GET /country-rules call your integration already makes at send-time can run at choose-time instead, and the whole surprise class disappears.

​
First send plan: a combined US + India + Brazil launch

A combined launch across required regimes works — as long as the work is sequenced differently per regime rather than waiting for one global gate. The example below plans US 10DLC + India DLT + Brazil alphanumeric from a single launch date.
1

Week 0 — start every registration track in parallel

Upload your KYC documents once under KYC Documents, then start all three tracks the same day:
  • US — register the 10DLC brand and campaign, and do not wait on it before starting the others.
  • India — start on a DLT registrar’s portal (Principal Entity, then Headers, then content templates; see DLT-India).
  • Brazil — submit the Sender-ID registration for BR with the uploaded documents (Sender-ID Registration).
2

Week 1–2 — send to whichever markets come back approved first

Approvals land on a different clock per regime. The DLT window (1–7 days) often clears before 10DLC vetting (1–2 weeks), which clears before a long-market Sender-ID queue (day-to–weeks). Treat each approved country as independently launchable — do not hold the launch for the slowest market.
3

Launch — gate-check each market before each first send

A market only unblocks when its registration is approved, so a 422 from one gate does not roll back the others. If a gate holds, keep sending to the already-approved markets while the remaining registration clears. Same-launch orchestration across regimes is a checklist habit, not a single gate.
Two regime-specific notes from the chooser — the matrix tables name them because they change the shape of the plan, not the order:
  • India on DLT — messages are template-bound: pre-register each message body as a content template tied to your Header, or the operator rejects it even when your PE and Header are approved. See DLT-India onboarding.
  • US on 10DLC — approval here is a brand + campaign, not a Sender ID. Brand-only approval does not clear the vetting step. See 10DLC Registration.

​
Limits of this page

This page is a chooser view, not the regulatory record. Use it to rank candidate markets before committing to them — when a market makes it into your send plan, open the full profile before submitting:
  • Authoritative values per market always live in Country Compliance Requirements; the lead-time and document-class rows above point into it, they do not replace it.
  • The Sender-ID Registration reference and Send Gates are the submission + enforcement surfaces; this page only maps the required class triage.
  • Regulator-defined windows shift. Confirm the live registration and sender_rules fields on the GET /country-rules endpoint before committing to a launch date.