Sender-ID registration by market: the per-market walkthrough

The Sender-ID country matrix tells you which markets gate on registration. This page is the walkthrough for doing one market end to end: which channels the registration actually covers, which document roles to pre-upload, what a complete filing looks like, how long the approval queue runs, and how to read the GET /compliance/country-rules row before you file. Work through it once per market, before you commit to a launch date. Everything here is a control you own as the tenant — Orbit carries the filing to the regulator or carrier and enforces the gate; the underlying documents and the launch sequencing stay with you.

Approval is granted by the regulator or carrier in each country, not by Orbit — lead times below are planning windows, and a market listed here is not necessarily enabled on your account.

1. Start from the matrix

Begin on the Sender-ID country matrix: one registration value per candidate market — none, recommended, or required. When a market lands in required, come to this page. The matrix is the chooser; this walkthrough is the runbook for the markets you picked.

2. Derive the channel scope, then the document pack

Two questions settle most of the filing: which channels do you plan to send over in this market? and which sender identity does each channel use? The answers pick the registration regime and the document pack.

2.1 Channel scope per sender identity

Call the country-rules endpoint once per channel — the same country answers to a different regulator per channel:

for channel in sms whatsapp rcs; do
  curl -s "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=$channel" \
    -H "Authorization: Bearer $ORBIT_API_KEY" \
  | jq '.data.rows[] | select(.country_code=="BR") |
        {channel: .channel, registration: .registration,
         sender_types: .sender_types, rules: .sender_rules}'
done

Channel	Sender identity	How you register
SMS	Alphanumeric Sender ID, long code, or short code	The generic Sender-ID Registration flow — document refs by `doc_…` ID per country.
WhatsApp	A WhatsApp Business Account (WABA) sender	Meta business verification, not the Sender-ID flow. A country-agnostic compliance profile with `use_case: whatsapp_business_verification` backs it.
RCS	A verified RCS Business Messaging agent	Carrier brand verification, not the Sender-ID flow. A country-agnostic profile with `use_case: rcs_brand_verification` backs it.
Voice	Number-based	Voice traffic identifies by the calling number. Where a carrier demands identity behind the number, use a profile with `use_case: voice_carrier_kyc` — an alphabetic Sender-ID registration never gates voice.

Read sender_types on the row to confirm which of these the market even accepts for SMS — a market that lists only long_code does not take an alphanumeric filing, and re-submitting one earns an unwinnable rejection. The full use_case mapping is on KYC identity model.

2.2 Assemble the document pack

Upload every document once into the tenant-wide document library, then reference it by its doc_… ID. Where the market attaches documents to a compliance profile (WhatsApp, RCS, voice-KYC) you attach in a named role; the Sender-ID filing itself references doc_… IDs directly. Either way, name the role the document plays:

Role	Typical evidence
`business_doc`	Certificate of incorporation, business license, VAT certificate — the anchor of nearly every pack.
`id_proof`	Passport, national ID card, or driver’s license — markets that vet an individual signatory.
`address_proof`	Utility bill, bank statement, or lease agreement naming the registered entity.
`authorization`	Trademark record, trade-name filing, or a letter of authorization — mandatory when an agency or reseller files a client’s brand.
`other`	Anything a specific regulator demands beyond the four above.

Upload through KYC documents: POST /compliance/documents as a multipart form (type=…, country_code=…, file=@…), which returns the doc_… ID. JPEG, PNG, WebP, or PDF, up to 10 MB. Pre-upload the whole pack before you open a registration screen — a half-attached filing is the most common reason a submission sits unreviewable.

2.3 Read the expected lead time

Lead time belongs to the registration class, not to Orbit’s submission. The planning windows per class are documented on Sender-ID Registration:

Registration class	Typical window
Alphanumeric — pre-registration markets	1 day – 6 weeks (most of Africa, South Asia, South America, the Middle East sit at the long end)
Alphanumeric — dynamic / no-registration markets	Same day (register for provenance anyway)
Long code (numeric sender)	Same day – 3 days
US 10DLC (brand + campaign)	1 – 2 weeks
US/Canada short code	6 – 12 weeks
US toll-free number	1 – 3 days
India — DLT Headers	1 – 7 days

Budget the long end of the window when the launch date matters, and submit the pack complete the first time — missing or inconsistent documents are the usual cause of a queue reset, not the regulator itself.

3. Sample registration packs per market

Reuse works at the document level: one upload, many consumers. A complete BR pack reuses the same business_doc evidence for SA, AE, and UK where each market accepts it — add market-specific evidence only where the regulator demands it.

Brazil (SMS, alphanumeric) — full pack

Anatel blocks unregistered alphabetic senders outright; the pre-registration window runs to the long end. File the full pack from day one:

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/documents \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -F "type=business_registration" \
  -F "country_code=BR" \
  -F "file=@/docs/incorporation.pdf"

Role in pack	Document type	Why it is there
`business_doc`	`business_registration`	Proves the legal entity behind the sender.
`authorization`	`power_of_attorney` or trademark record	Proves the brand name is yours — or the owner authorized you to file it.
`other`	`notes` field on the filing	The use case (transactional, OTP, marketing) and the audience.

Then file the registration:

curl -X POST https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sender_id": "MyBrand",
    "countries": [
      {
        "country": "BR",
        "document_refs": ["doc_bizreg_1", "doc_brandauth_1"],
        "notes": "Transactional + OTP traffic to retail customers in Brazil"
      }
    ]
  }'

United Kingdom (SMS, alphanumeric) — lighter pack

Ofcom requires registration on a shorter domestic window. A business_doc evidence file plus the use-case notes usually completes the pack; drop the brand-authorization file only if your entity name and sender name match exactly.

Saudi Arabia / UAE (SMS, alphanumeric name)

CITC and TDRA register the sender name, not just the identifier. Attach business_doc plus an authorization that names the exact sender string — casing included. Reviewers decline filings where the name on the letter does not match the sender_id field verbatim. UAE adds a heavier KYC-backed identity expectation; Saudi can also bottle up on local entity presence — check sender_rules on the row first.

Reuse matrix

Market	Pack contents	Reuses
BR	`business_doc` + `authorization` + use-case `notes`	The baseline pack — everything else reuses part of it.
UK	`business_doc` + use-case `notes`	BR’s `business_doc`.
SA / AE	`business_doc` + `authorization` (exact-name) + use-case `notes`	BR’s `business_doc`; SA/AE add their own name-exact `authorization`.
FR / EU dynamic markets	`business_doc` only (recommended, not required)	Same `business_doc`; register for provenance.
US (10DLC)	EIN-backed brand registration, then campaign	Documents back the brand; campaigns are separate. See 10DLC Registration.
IN (DLT)	PE registration (PAN/GSTN), Headers, content templates	Regulated outside this flow. See DLT-India.

One upload, many rows. The reuse ceiling — “as many countries as accept it” — is the thing to plan for when you pick the first market’s evidence: capture the most reusable form of the document the first time (registered entity name matching the letterhead, address current, file clean), and the second and third filings reuse it without a second upload.

4. Decode the country-rules row before you file

The row is short; each field settles a different question:

{
  "country_code": "BR",
  "channel": "sms",
  "sender_types": ["alphanumeric", "long_code"],
  "registration": "required",
  "sender_rules": "Alphabetic sender IDs blocked unless pre-registered. Numeric senders accepted.",
  "content_restrictions": "Marketing SMS requires prior opt-in.",
  "stop_requirement": "STOP keyword mandatory.",
  "two_way": false,
  "dlr_support": "partial",
  "default_tps": "5"
}

Field	What it settles for the walkthrough
`sender_types`	Whether an alphanumeric filing is even winnable here.
`registration`	Which queue you join at all (`none` → register for provenance; `required` → gate blocks until `approved`).
`sender_rules`	The regulator’s exact nuance — dynamic vs. pre-registered, name vs. ID, format. Quote it back into the registration `notes` when the wording is load-bearing.
`content_restrictions`	Which use-case wording belongs in `notes`; marketing filings into a transactional-only regime get declined.
`stop_requirement`	The opt-out keyword you must render in the message body — unrelated to registration, checked at send time anyway.
`two_way`, `dlr_support`, `default_tps`	Delivery shape after launch; plan them with the same row.

The row is the contract the send gate enforces; decode it before the filing goes in, and re-check it whenever you add a channel to the market.

5. Troubleshooting pointers

A filing that does not move lands in one of three states; the fixes live on the troubleshooting pages that already own them:

Symptom	Where to go
Country entry stuck at `rejected` — length, format, ownership, use-case, stale or wrong documents	Sender-ID registration resubmit — read the rejection per failing country, fix the named item, re-submit.
Registration exists but the send still gates	Sender-ID not registered — the entry exists but its `status` is not `approved`; re-check and verify.
Wrong sender type filed into a strict market	Strict sender-ID invalid destination — the opt-in format gate fired; pick a different sender identity instead of re-filing.
A document expired after the filing was approved	KYC documents — replace with a fresh upload, re-attach in the same role, and re-submit the registration with the new `doc_…` ID (approved countries keep their status across the swap).
A rejection you cannot decode	The rejection-cause table on Sender-ID registration resubmit covers the usual shapes; escalate to support@devotel.io with the tenant ID, `sender_id`, failing country, and what you changed.

6. Downloadable checklist

Copy this straight into your launch ticket — one row per market:

Market: <ISO-2>                      Channel: <sms | whatsapp | rcs | voice>
[ ] 1. Country-rules read           row decoded; sender_types accepted
[ ] 2. Registration regime          none / recommended / required chosen
[ ] 3. Documents pre-uploaded       business_doc (+ id_proof) (+ address_proof) (+ authorization)
[ ] 4. Sender-ID filed              POST /sender-id-registrations, refs attached
[ ] 5. Lead-time budgeted           class window on the launch plan
[ ] 6. Status polled to approved    per-country entry reads approved
[ ] 7. First send gate-checked      422 table walked
[ ] 8. Renewal horizon calendared   alert window set (30-day default)

The checklist is the walk-through at pocket size: if a row is unchecked, the filing is not done, and a required market will gate the first send.

Sender-ID country matrix — the chooser this walkthrough executes.
Sender-ID Registration — the filing and status surface.
Country Compliance Requirements — the flat per-country reference the matrix curates.
KYC identity model — the document, profile, and destination triangle.
KYC documents — the document library.
Send Gates — how required markets block at send time.
10DLC Registration — the US brand + campaign flow.
DLT-India Onboarding — India’s header and content-template regime.

Getting Started

Channels

Channels (Voice)

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Brand & press

Changelog

Sender-ID registration by market: the per-market walkthrough

Sender-ID registration by market: the per-market walkthrough

1. Start from the matrix

2. Derive the channel scope, then the document pack

2.1 Channel scope per sender identity

2.2 Assemble the document pack

2.3 Read the expected lead time

3. Sample registration packs per market

Brazil (SMS, alphanumeric) — full pack

United Kingdom (SMS, alphanumeric) — lighter pack

Saudi Arabia / UAE (SMS, alphanumeric name)

Reuse matrix

4. Decode the country-rules row before you file

5. Troubleshooting pointers

6. Downloadable checklist

​Sender-ID registration by market: the per-market walkthrough

​1. Start from the matrix

​2. Derive the channel scope, then the document pack

​2.1 Channel scope per sender identity

​2.2 Assemble the document pack

​2.3 Read the expected lead time

​3. Sample registration packs per market

​Brazil (SMS, alphanumeric) — full pack

​United Kingdom (SMS, alphanumeric) — lighter pack

​Saudi Arabia / UAE (SMS, alphanumeric name)

​Reuse matrix

​4. Decode the country-rules row before you file

​5. Troubleshooting pointers

​6. Downloadable checklist

​Related references

Sender-ID registration by market: the per-market walkthrough

1. Start from the matrix

2. Derive the channel scope, then the document pack

2.1 Channel scope per sender identity

2.2 Assemble the document pack

2.3 Read the expected lead time

3. Sample registration packs per market

Brazil (SMS, alphanumeric) — full pack

United Kingdom (SMS, alphanumeric) — lighter pack

Saudi Arabia / UAE (SMS, alphanumeric name)

Reuse matrix

4. Decode the country-rules row before you file

5. Troubleshooting pointers

6. Downloadable checklist

Related references