Country Compliance Requirements

Messaging and voice rules are set country by country. Before you send to a new market you need to know four things: which sender types that country accepts (a long code? an alphanumeric Sender ID? a short code?), whether registration is required, what documents you must supply, and which content is restricted. Getting this wrong is the most common reason first sends to a new country silently fail to deliver. Orbit maintains a curated, per-country regulatory reference so you do not have to assemble this yourself. This page explains how to read it.

This reference is guidance to help you plan, not a delivery guarantee or legal advice. Final approval of a Sender ID or registration is granted by the regulator or carrier in each country, not by Orbit. Coverage is enabled per tenant — a country appearing here does not mean it is enabled on your account.

Look up a country’s rules

GET /compliance/country-rules is the read-only regulatory reference behind Orbit’s send-time gates. Any authenticated user can call it. Filter by channel (defaults to sms) and optionally by region:

curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms&region=EU" \
  -H "Authorization: Bearer $ORBIT_API_KEY"

Each row describes one country × channel:

{
  "data": {
    "rows": [
      {
        "country_code": "FR",
        "channel": "sms",
        "country_name": "France",
        "calling_code": "33",
        "region": "EU",
        "sender_types": ["alphanumeric", "long_code"],
        "registration": "recommended",
        "sender_rules": "Alphanumeric sender IDs are dynamic; no pre-registration required but recommended for consistency.",
        "content_restrictions": "Marketing SMS requires prior opt-in (GDPR). No sends 20:00–08:00 or Sundays/holidays.",
        "stop_requirement": "STOP keyword mandatory in French (STOP au 36111).",
        "two_way": true,
        "dlr_support": "full",
        "default_tps": "10",
        "notes": ""
      }
    ],
    "channel": "sms",
    "last_synced_at": "2026-06-20T00:00:00.000Z",
    "total": 1
  },
  "meta": { "request_id": "…", "timestamp": "2026-06-20T12:00:00.000Z" }
}

The channel filter accepts sms, whatsapp, rcs, voice, email, and viber. The same country has separate rows per channel because different channels answer to different regulators — for example Meta’s WABA rules govern WhatsApp in Brazil while Anatel’s rules govern SMS.

Reading each field

Field	What it tells you
`sender_types`	Which “from” identities the country accepts — see the table below.
`registration`	`none`, `recommended`, or `required` — whether you must register a Sender ID before sending.
`sender_rules`	Plain-language notes on how sender IDs behave in that country (dynamic vs. pre-registered, number format, etc.).
`content_restrictions`	Category and consent restrictions — e.g. “marketing requires opt-in”, promotional-content bans. See Restricted & Prohibited Industries.
`stop_requirement`	Whether an opt-out keyword is mandatory and in what language.
`two_way`	Whether inbound replies are supported.
`dlr_support`	Delivery-receipt fidelity: `full`, `partial`, `submitted_only`, or `none`.
`default_tps`	The default throughput ceiling (messages per second).

Sender types

Value	Meaning
`alphanumeric`	A branded text Sender ID (e.g. `MyBrand`).
`numeric`	A numeric sender that is not a routable long code.
`long_code`	A standard local/mobile long number.
`short_code`	A dedicated 4–6 digit short code.
`ten_dlc`	A US 10-digit long code registered through 10DLC.
`waba`	A WhatsApp Business Account sender.
`rcs_agent`	A verified RCS Business Messaging agent.
`from_address`	An email `from` address (email channel).

The `registration` levels

The registration field is the single most important value to read before launching. It drives Orbit’s send-time gate:

none — send freely

No Sender-ID registration is required. You can start sending once the channel and country are enabled on your account.

recommended — send now, register for reliability

Sending is allowed without registration, but unregistered traffic is more likely to be filtered or relabelled. Register the Sender ID to keep delivery stable.

required — register before you send

Traffic is blocked until you have an approved Sender-ID registration for the country. A2P SMS to a required country with no approved entry is held by the send-time gate. Register and get approved before launch — see Sender-ID Registration.

Documentation each country expects

Where a country requires (or recommends) registration, you submit supporting documents once, then reference them by their doc_… IDs when you register a Sender ID. The exact set varies by market, but most regulators ask for some combination of:

Proof of business registration — certificate of incorporation, business license, or equivalent.
A use-case description — what you send (transactional, OTP, marketing) and to whom.
Brand ownership / authorization — proof you are entitled to the Sender ID / brand name you are registering.
Local tax or regulator ID — for markets that key registration to a national identifier.

Read the target country’s sender_rules and content_restrictions in the country-rules response for the specifics, then attach the matching documents when you submit the registration. Some markets run their own dedicated registration regime rather than the generic Sender-ID flow:

India — Sender IDs (“Headers”), content templates, and consent templates register through the TRAI DLT portal. See DLT-India Onboarding.
United States — A2P SMS senders register a brand and campaign via 10DLC. See the 10DLC Registration guide.

A launch checklist for a new country

Look up the rules

Call GET /compliance/country-rules?channel=<channel> for the destination and read sender_types, registration, and content_restrictions.

Pick an accepted sender type

Choose a sender identity from that country’s sender_types — an alphanumeric Sender ID, a long code, a short code, or a channel-native sender (WABA / RCS agent).

If registration is required (or recommended), upload your documents and submit the Sender ID for approval. Plan lead time — some markets take days to weeks.

Check content restrictions

Confirm your use case is allowed against content_restrictions and Restricted & Prohibited Industries, and add the required opt-out keyword if stop_requirement calls for one.

Launch

Once the country is enabled, the sender type is accepted, and any required registration is approved, start sending.

Maintaining the rules source (platform operators)

This section is for platform operators and self-hosted deployments. SaaS customers on api.orbit.devotel.io can stop here — Devotel keeps the country rules current for you, and the endpoints below are gated to platform admins.

The country-rules reference is fed by scheduled upstream syncs plus manual operator edits. This section covers how to keep it fresh and how to edit a single country safely. The endpoints that write to the rules table are platform-admin only — tenant owners and admins get a 403, because the rules table is global across all tenants, not per-tenant data.

Feed sources

Each row’s sync_source records which feed last refreshed it. Six providers plug into the sync endpoint:

Provider	What it supplies	Access
`mef`	MEF SenderID Protection Registry — MNO-signed sender-ID rules (the most authoritative sender-ID source)	Paid Aggregator-tier membership; set `DEVOTEL_MEF_API_KEY`
`gsma`	GSMA SMS Hub sender-ID protection rules	Member portal; set `DEVOTEL_GSMA_API_KEY`
`telnyx`	Country coverage via the Telnyx coverage feed	Free with `DEVOTEL_TELNYX_API_KEY`; falls back to Telnyx’s public coverage list when unset
`iconectiv`	iconectiv TCR partner feed — the canonical US 10DLC ruleset	Set `DEVOTEL_TCR_API_KEY` + `DEVOTEL_TCR_PARTNER_ID`; see the 10DLC guide
`meta`	Meta Business API — per-country WhatsApp (WABA) availability	Free with a WABA system-user token
`itu`	ITU WTID — national regulator reference URLs	Free (attribution required)

Two adjacent feeds feed their own tables:

Telnyx coverage for the legacy sender-ID matrix — the read endpoints behind the sender-ID compliance matrix draw from a separate legacy table. Refresh it with POST /api/v1/compliance/admin/sync (admin only; same weekly scheduler also refreshes it automatically).
Reassigned Numbers Database (RND) — the US disconnected-number gate documented under Deactivation scrubbing. Tenants enable it per tenant via PUT /api/v1/compliance/rnd/settings with { "enabled": true }; the toggle refuses to switch on until an operator has loaded an RND snapshot into the deployment, so tenants cannot opt into an empty gate.

Run an upstream sync

POST /api/v1/compliance/country-rules/sync refreshes from one provider. Pick the feed with ?provider= (defaults to telnyx) and optionally scope to one ?channel=.

curl -X POST "https://api.orbit.devotel.io/api/v1/compliance/country-rules/sync?provider=mef&channel=sms" \
  -H "Authorization: Bearer $ORBIT_PLATFORM_ADMIN_KEY"

The response reports upstreamCount, updated, createdNew, and an errors array. A sync never overwrites operator-curated prose — only structural fields (country name, calling code, region, sender types, registration level) are refreshed; the free-text fields (sender_rules, content_restrictions, notes) keep whatever an operator last wrote.

Feed cadence

Two paths keep the table current:

Weekly scheduler — the webhook-worker’s compliance-sync tick runs the Telnyx, MEF, and GSMA feeds automatically. It also runs once at worker startup, so a fresh deployment seeds itself on first boot.
On-demand — the admin “Refresh from upstream” action calls the sync endpoint above for an immediate pull (useful right after you provision a new feed credential).

Staleness is checked against last_synced_at, which the read endpoint returns alongside the rows. Manual edits stamp last_reviewed_at instead, so the dashboard can show provenance (“Synced from MEF 3 days ago; reviewed by ops yesterday”) rather than a single ambiguous timestamp.

Failure handling

Every connector is optional and fail-open: when its credential env var is unset the sync logs a skip message and returns an entry in errors, and existing rows stay in place. The same applies on an upstream outage — the response carries the error text while previously synced data remains readable. These are read-only metadata feeds on a lookup path; outbound messaging continues to route through your normal sender while a feed is down.

Sync providers touch only coverage metadata. They are never a transport path — do not attempt to route outbound messaging through any of the coverage feeds listed here.

Edit a single country

PUT /api/v1/compliance/country-rules/:channel/:country_code upserts one country × channel row. Use it to supply details no feed carries — for example STOP-keyword wording or throughput limits picked up from regulator text. Platform-admin credentials are required; tenant admins receive a 403.

curl -X PUT "https://api.orbit.devotel.io/api/v1/compliance/country-rules/sms/FR" \
  -H "Authorization: Bearer $ORBIT_PLATFORM_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "country_name": "France",
    "calling_code": "33",
    "region": "EU",
    "sender_types": ["alphanumeric", "long_code"],
    "registration": "recommended",
    "sender_rules": "Alphanumeric sender IDs are dynamic.",
    "content_restrictions": "Marketing SMS requires prior opt-in.",
    "stop_requirement": "STOP keyword mandatory in French.",
    "two_way": true,
    "dlr_support": "full",
    "default_tps": "10",
    "notes": ""
  }'

Editable fields: sender_types, registration (none / recommended / required), sender_rules, content_restrictions, stop_requirement, two_way, dlr_support, default_tps, notes, and sources (a [{ label, url }] list of attribution links). The upsert stamps last_reviewed_at and marks the row sync_source: manual, so a later auto-sync refreshes only the structural fields and leaves your prose alone.

Validation checklist before you flip a country live

Before you turn a country on for sending, confirm:

Fresh sync stamp

last_synced_at (or, for the legacy matrix, last_verified_at) is recent — otherwise run the on-demand sync for the relevant provider before enabling.

Correct registration level

registration is set (none / recommended / required). A required country blocks unregistered traffic at send time, so a missed registration review means failed sends, not delayed ones.

Prose fields reviewed

stop_requirement and content_restrictions say what they should — feeds only refresh structure, so prose must be set by an operator.

Sender type accepted

At least one of the country’s sender_types matches what you plan to send from.

Related gates loaded

If the destination has an RND or DLT gate (US RND, India DLT), confirm that feed is loaded too — see Deactivation scrubbing and DLT-India Onboarding.

Restricted & Prohibited Industries — which industries and content are restricted or banned.
Sender-ID Registration — submit and track Sender-ID registrations per country.
DLT-India Onboarding — India’s TRAI DLT regime.
10DLC Registration — US A2P brand and campaign vetting (includes the country-rule feed configuration for operators).
Send Gates — the gates that enforce these rules at send time.
Network signals before you send — screen recipients with operator-asserted SIM-swap, roaming, and risk signals before a first send to a new destination.
API Reference → Compliance — full request/response schemas.

Getting Started

Channels

Channels (Voice)

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Changelog

Country Compliance Requirements

Country Compliance Requirements

Look up a country’s rules

Reading each field

Sender types

The `registration` levels

Documentation each country expects

A launch checklist for a new country

Maintaining the rules source (platform operators)

Feed sources

Run an upstream sync

Feed cadence

Failure handling

Edit a single country

Validation checklist before you flip a country live

​Country Compliance Requirements

​Look up a country’s rules

​Reading each field

​Sender types

​The registration levels

​Documentation each country expects

​A launch checklist for a new country

​Maintaining the rules source (platform operators)

​Feed sources

​Run an upstream sync

​Feed cadence

​Failure handling

​Edit a single country

​Validation checklist before you flip a country live

​Related references

Country Compliance Requirements

Look up a country’s rules

Reading each field

Sender types

The `registration` levels

Documentation each country expects

A launch checklist for a new country

Maintaining the rules source (platform operators)

Feed sources

Run an upstream sync

Feed cadence

Failure handling

Edit a single country

Validation checklist before you flip a country live

Related references