> ## 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. # Multi-region sender-identity decision walkthrough > One global planning path for senders entering APAC, Europe, LATAM, and MENA at once — pick sender type and channel per market from a single decision table, run the country-capabilities pre-flight, do one worked market per region, and decode the error codes and per-market quiet-hours posture. # Multi-region sender-identity decision walkthrough The regional playbooks — [APAC](/guides/asia-channels-onboarding), [Europe](/guides/europe-channels-onboarding), [LATAM](/guides/latam-channels-onboarding), [MENA](/guides/mena-channels-onboarding) — each walk one region well. When you enter several regions at once, you need one planning path that decides, per market, the same four things: **which sender type**, **which channel**, **which registration**, and **which tenant-owned send posture**. This page is that convergence. It routes; the regional playbooks do the step detail. Use the tables below to build your launch plan market by market, then run only the sections of each regional playbook for your chosen channels. The [Sender-identity onboarding map](/guides/sender-identity-onboarding-map) remains the router for what your sender **is** (person, org brand, campaign draft); this walkthrough is the router for where it **goes**. ## 1. Sender-type decision table — per market regime Every destination market falls into one sender regime. Pick your markets in this table first; the `required` regimes gate your sends with a `422` until registration is approved. | Market class | Sender regime | Registration | Worked market below | | - | - | - | - | | United States | 10DLC brand + campaign on long codes; toll-free numbers need TFV | [10DLC registration](/guides/10dlc-registration), [Toll-free verification](/guides/toll-free-verification) | US ([Europe path covers US-adjacent picks](#4-end-to-end-worked-examples)) | | India | DLT template filing registers the content, not just the identity | [DLT India onboarding](/guides/dlt-india-onboarding) | India (APAC example) | | GCC (UAE, Saudi Arabia) | Alphabetic Sender-ID pre-registration — `required` gate | [Sender-ID registration by market](/guides/sender-id-registration-by-market) | UAE (MENA example) | | North Africa (e.g. Morocco) | Numeric sender vs alphabetic — check the country row before launch | [Sender-ID country matrix](/guides/sender-id-country-matrix) | covered in the MENA playbook | | Brazil (LATAM example) | WhatsApp default with SMS fallback | [LATAM channels onboarding](/guides/latam-channels-onboarding) | Brazil (LATAM example) | For every row, the per-market walkthrough — [Sender-ID registration by market](/guides/sender-id-registration-by-market) — gives the document roles, lead times, and the country-rules read before you file. ## 2. Pre-flight check — capabilities first, KYC in this order Before you activate a channel for any market: 1. **Check number stock and capabilities** — `GET /api/v1/numbers/country-capabilities?country=` tells you what (line type × capability) is actually available before you search; the [country-capabilities page](/numbers/country-capabilities) documents the response shape. Pick the sender type from real stock, not from a wish list. 2. **Run the KYC chain in order**: [organization KYC](/guides/organization-kyc-onboarding) → [compliance profile](/guides/compliance-profiles-assemble) → per-market [Sender-ID registration](/guides/sender-id-registration-by-market). The verified KYC packet is reused; a per-market gating order means later channels reuse the same approved profile. 3. **Read the destination rules** on [country requirements](/compliance/country-requirements) before assuming one registration covers all your traffic classes. 4. **Dry-run the campaign** (`POST /api/v1/campaigns/:id/dry-run`) — the read-only [campaign end-to-end](/guides/campaign-end-to-end) flow's preview surface returns `warnings: []` or names the missing registration before launch fails. ## 3. Channel pick per market — one consistent schema The four regional playbooks carry this same pick table; keep the schema identical when you extend a region page. | Region | Default channel | Fallback | Template duty | Sender-id regime | | - | - | - | - | - | | APAC (Japan, Thailand, Taiwan) | LINE | SMS | template-free on LINE | profile channel (Official Account) | | APAC (India) | SMS (DLT template) | WhatsApp | DLT template filing | DLT content registration | | Europe | WhatsApp (WABA) or RCS | SMS | WABA templates / RCS rich cards | alphanumeric sender-id, 2-way numbers | | LATAM | WhatsApp | SMS | WABA templates | WhatsApp profile; SMS sender rules per country | | MENA (GCC) | SMS (alphabetic sender-id) | WhatsApp | sender-id pre-registration; Arabic-first templates | alphabetic sender-id `required` | Pick one default per market and one fallback; do not activate every channel everywhere. ## 4. End-to-end worked examples — one market per region The signature you are proving in every example: a `ready` sender row, an approved registration, a connected channel, an approved template where the market files content, a `202` first send, and a delivery-status webhook that lands `delivered`. **US (Europe path's US-adjacent pick).** 10DLC brand → campaign → number assignment. Follow the [10DLC wizard](/guides/10dlc-wizard) end to end: brand (`entity_type`), campaign (`usecase`, sample messages, opt-in flow), atomic preflight + submit, poll `GET /10dlc/wizard` to `state: "ready"`, then assign numbers. For toll-free add [TFV](/guides/toll-free-verification). Done-state: the [verifications timeline](/guides/verifications-timeline) shows both rows Approved with 0 pending. **India (APAC example).** Register the DLT template content per market, then send SMS against the approved template with WhatsApp as fallback. Done-state: the template id is approved in the DLT console **and** the first single send returns `202`; the DLR webhook advances to `delivered`. **UAE (MENA example).** File [organization KYC](/guides/organization-kyc-onboarding), assemble the [compliance profile](/guides/compliance-profiles-assemble), then file the sender-id registration per destination on [Sender-ID registration by market](/guides/sender-id-registration-by-market). Done-state: **Settings → Compliance → Sender IDs** reads the sender name approved for the destination without which a send is a `422`. **Brazil (LATAM example).** Connect a WhatsApp Business account per the [LATAM channels onboarding](/guides/latam-channels-onboarding); SMS is the fallback. Done-state: the campaign [dry-run](/guides/campaign-end-to-end) returns `warnings: []` before launch and the status webhook lands on a terminal `delivered`. ## 5. Error-code atlas per region The codes are the same platform-wide; the cause per region differs. | Code | Region cause | Fix | Troubleshooting | | - | - | - | - | | `SENDER_NOT_REGISTERED` / gated `422` | GCC / North America / India rows that filed registration but not per-market, or a number not yet assigned into a campaign. | File the per-market registration, assign the number into the campaign, re-dry-run. | [Sender ID not registered](/troubleshooting/sender-id-not-registered) | | `KYC_HOLD` / pending gating | Org KYC packet incomplete or the approved profile is still in `pending_review`. | Complete the KYC packet; wait for the profile to flip `approved`. | [Troubleshooting compliance error codes](/compliance/troubleshooting-compliance-error-codes) | | `VALIDATION_ERROR` on template sends | Template markets (India DLT, WhatsApp WABA, WeChat, KakaoTalk Alimtalk, Zalo ZNS) reject a missing or unapproved `template_name`. | Approve templates and select them by id. | [Reference: error codes](/reference/error-codes) | The full enforcement list lives on the [error-codes reference](/reference/error-codes); the gates are sender-side before platform-side. ## 6. Tenant-owned posture checklist — quiet hours and frequency caps Registration completeness is a carrier/registry question; the following controls are yours to configure per tenant. Orbit carries the filing to the relevant regulator or carrier. * **Quiet hours** — set per-market rules in [quiet-hours configuration](/guides/quiet-hours-configuration); the [quiet-hours checker](/guides/quiet-hours-checker-tool) dry-runs a send window across markets. DST boundaries live on [quiet-hours DST crossover](/guides/quiet-hours-dst-crossover). * **Frequency caps** — [frequency caps](/guides/frequency-caps) enforce per-recipient send limits; tune per market. The [campaign limits & quiet hours](/guides/campaign-limits-quiet-hours) page pairs both with campaign-level norms. * **One gate to walk** — before any launch, run the [pre-flight checklist](/guides/send-gates-preflight-checklist): wallet, opt-out sync, quiet hours, frequency caps, and the TCPA window re-checked in admission order. This is a tenant-owned checklist by design: Orbit enforces the gate and carries the filing, but the underlying documents, per-market quiet-hours windows, and launch sequencing stay with you. ## Where this page sits * [Sender-identity onboarding map](/guides/sender-identity-onboarding-map) — routes by what the sender is. * This page — routes by where it goes. * Per region, the playbooks: [APAC](/guides/asia-channels-onboarding), [Europe](/guides/europe-channels-onboarding), [LATAM](/guides/latam-channels-onboarding), [MENA](/guides/mena-channels-onboarding) — do the step detail.