​

Multi-region sender-identity decision walkthrough

The regional playbooks — APAC, Europe, LATAM, MENA — 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 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. For every row, the per-market walkthrough — 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=<ISO> tells you what (line type × capability) is actually available before you search; the country-capabilities page 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 → compliance profile → per-market Sender-ID registration. 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 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 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. 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 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. Done-state: the 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, assemble the compliance profile, then file the sender-id registration per destination on 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; SMS is the fallback. Done-state: the campaign dry-run 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. The full enforcement list lives on the error-codes reference; 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; the quiet-hours checker dry-runs a send window across markets. DST boundaries live on quiet-hours DST crossover.
• Frequency caps — frequency caps enforce per-recipient send limits; tune per market. The campaign limits & quiet hours page pairs both with campaign-level norms.
• One gate to walk — before any launch, run the pre-flight checklist: wallet, opt-out sync, quiet hours, frequency caps, and the TCPA window re-checked in admission order.

​

Where this page sits

• Sender-identity onboarding map — routes by what the sender is.
• This page — routes by where it goes.
• Per region, the playbooks: APAC, Europe, LATAM, MENA — do the step detail.