Skip to main content

​
Compliance-profile use cases and the surface each one opens

Every gated surface on Orbit names a packet: the kind of compliance profile (cprof_…) it expects before a phone number activates, a Sender ID carries traffic, or a sender identity goes live. The profile has a use_case field with ten possible values — and reading a destination’s rules tells you which of the ten you owe. This page is the matrix: each use case, the gate it unlocks, and the countries that require it. If you are importing a contact list or standing up a new market, decide here which packet(s) to assemble before you upload a document or buy a number.
Compliance posture is tenant-owned. Orbit gives you the control surface and defaults it open; you choose the packet for each surface. Final approval of any packet comes from the carrier or regulator in the destination country, not from the platform.

​
The use_case → gate matrix

A profile answers one gate. The gate a surface enforces maps to one of the ten use_case values below — set the right value at profile creation, because the carrier grades the packet against the rules for that use case, not “anything you submitted.” Country-agnostic gates (WhatsApp, RCS, email categories) accept a profile with no country_code; number, sender-ID, and 10DLC use cases usually require one. Check the target country’s row in GET /compliance/country-rules before you create the profile. Each surface’s documents are the same doc_… library files — upload once in the library, then reference on every profile that accepts them. See KYC Documents & the Compliance-Profile Lifecycle.

​
Which countries require which use case

Read the country-rules row for the destination and channel — the reference is per-country × per-channel so you see exactly which gate applies:
  • registration: required | recommended | none on the row tells you whether a packet is a hard gate or advice.
  • The row’s sender_types tell you which sender identity that channel accepts (ten_dlc, alphanumeric, long_code, waba, rcs_agent, from_address).
Match the gate to the use case: US ten_dlc → sms_10dlc_*; an alphanumeric destination → sms_sender_id_alphanumeric; a WhatsApp or RCS channel → whatsapp_business_verification or rcs_brand_verification; email → email_domain_verification; a voice required row → voice_carrier_kyc; any regulated number destination → phone_number_purchase. For US SMS the two 10DLC values split: sms_10dlc_brand_us registers the brand, then sms_10dlc_campaign_us registers the actual campaign — the campaign is the gate send-time enforces; the brand alone does not open US A2P traffic. That layering is why the matrix separates them; the detail is in the sections below. See Country Compliance Requirements for the per-country read, and Sender-ID Registration for the sender-ID packet flow.

​
Campaign, not brand: the US messaging gate

US A2P SMS registers through 10DLC in two layers. The brand packet (sms_10dlc_brand_us) proves who you are to the carriers; the campaign packet (sms_10dlc_campaign_us) declares what you send and how. US destinations check the campaign at send time — a registered brand with no approved campaign still can’t send. Register the brand first (TCR vets it in ~1–2 days), then the campaign (~1–5 days of review); the campaign alone is the packet that opens US A2P traffic. Importing a list into the US without a campaign packet is the most common first-send failure. See 10DLC Registration for the linear flow, the 10DLC wizard for the save-and-resume drafts flow, and 10DLC rejections and re-vetting for fixing a rejected packet.

​
When one packet won’t open a surface

Two situations where a single use_case value is not enough:
  • US SMS on both 10DLC and toll-free origin types. Sending from a long code requires sms_10dlc_campaign_us; sending from a toll-free number requires sms_tfv_us instead. If you send from both kinds of origin, you owe both packets — one use case covers only its origin type.
  • A new channel added to an existing destination. The SMS gate you already opened with sms_sender_id_alphanumeric says nothing about WhatsApp or RCS on the same country — those channels run their own verification (whatsapp_business_verification / rcs_brand_verification). Once voice enters the mix, a country’s required voice row may demand voice_carrier_kyc on top.
In both cases the fix is one additional profile, not a new identity: the same doc_… documents often back the second packet.

​
Renewal: documents expire, pending_review pauses

A packet is durable but its documents and review state are not:
  • Documents age out. Orbit records an expires_at per attached document; when a document lapses it stops counting toward the country requirement and the profile reverts toward expired. Renew with a fresh upload before the date. The per-number alerts are documented under KYC Documents & the Compliance-Profile Lifecycle.
  • Re-submission moves to pending_review. Any edit you push into review pauses approval until it clears — the surface stays gated until the profile returns to approved. Read the timeline before you resubmit (for US 10DLC, see rejections and re-vetting).
Lead time on renewal is the same as lead time on first submission — plan it into the destination’s launch calendar, not after the number blocks.

​
Tenant-owned by design

The gate shape is tenant-owned: you choose which packets exist, which destination’s rules you answer to, and when to renew. The platform enforces the gate, carries the packet to the carrier, and reports its status — it never invents the packet for you. Importing a list without the destination’s required packet is a blocked send, not a delayed one; this page is how you decide which packet(s) to assemble before the list goes anywhere.