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).

​
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.