> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Sender-ID registration by market: the per-market walkthrough
> The runbook that sits under the country matrix: for each launch market, derive the channel scope, assemble the registration pack with document roles, read the expected lead time, and decode the country-rules row — with a checklist you can copy into your launch plan.
# Sender-ID registration by market: the per-market walkthrough
The [Sender-ID country matrix](/guides/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](/guides/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:
```bash theme={null}
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](/compliance/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](/compliance/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](/compliance/documents-kyc): `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](/compliance/sender-id-registration#approval-lead-times-by-registration-class):
| 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:
```bash theme={null}
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:
```bash theme={null}
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](/guides/10dlc-registration). |
| IN (DLT) | PE registration (PAN/GSTN), Headers, content templates | Regulated outside this flow. See [DLT-India](/compliance/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:
```json theme={null}
{
"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](/troubleshooting/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](/troubleshooting/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](/troubleshooting/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](/compliance/documents-kyc) — 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](/troubleshooting/sender-id-registration-resubmit) covers the usual shapes; escalate to [support@devotel.io](mailto: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:
```text theme={null}
Market: Channel:
[ ] 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.
***
## Related references
* [Sender-ID country matrix](/guides/sender-id-country-matrix) — the
chooser this walkthrough executes.
* [Sender-ID Registration](/compliance/sender-id-registration) — the filing
and status surface.
* [Country Compliance Requirements](/compliance/country-requirements) —
the flat per-country reference the matrix curates.
* [KYC identity model](/compliance/kyc-identity-model) — the document,
profile, and destination triangle.
* [KYC documents](/compliance/documents-kyc) — the document library.
* [Send Gates](/compliance/send-gates) — how `required` markets block at
send time.
* [10DLC Registration](/guides/10dlc-registration) — the US brand +
campaign flow.
* [DLT-India Onboarding](/compliance/dlt-india) — India's header and
content-template regime.