​

Sender identity onboarding map

Every outbound identity on Orbit passes through a registration sequence before carriers and registries treat its traffic as known. The sequence depends on what the sender is, not on anything Orbit screens for: a sole-proprietor person files differently from an organization brand, and a campaign that is still a draft files differently from both. This page routes you to the right sequence and tells you when the set is complete enough to walk the outbound pre-flight gates. Use the table to place your sender in one row, then read only that row’s section below — the owning guides carry the step detail on purpose, so this map stays a router, not a copy of them.

​

1. Decision card — which class is your sender?

Answer three questions in order; the first one that resolves picks your row.

1. Are you one person? A sole proprietor, or a founder sending under their own name, follows the person path — TCR brands a sole- proprietor brand on a personal identifier instead of a company registration. If you can produce a business registration (tax number, corporate filing), you are an org brand even with a single number.
2. Is the registry asking about a brand or about a campaign? Registrations land on a brand entity once; campaign drafts then attach to that approved brand. If you already have an approved brand and you are preparing a new use case or template, you are working a campaign draft, not on-ramping from zero.
3. Does the destination market file content, not identity? Regulated markets (US 10DLC use-case categories, India DLT templates) register the message itself. If a market check — not a new identity — is what stands between you and launch, treat the sender as a campaign draft and file the content.

When the answers conflict (a person inside an org, a campaign that doubles as brand onboarding), pick the row whose first registration you have not completed yet — the class is decided by the earliest outstanding filing.

​

2. Person path — sole proprietors and single-number senders

TCR supports a sole-proprietor brand registered on a personal identifier, and the 10DLC wizard walks that brand end to end with save-and-resume drafts, OTP verification of the proprietor’s phone, and an atomic submit. (If you send as a business, skip to the org path — sole-proprietor brands are capped at low throughput deliberately.) Once the brand approves, file the 10DLC campaign — the use-case declaration that carries throughput — and assign numbers into it; unassigned numbers send at unregistered-10DLC rates. The 10DLC rejections and re-vetting guide covers verdict handling if the vet comes back rejected.

​

3. Org brand path — businesses and multi-market senders

Start with organization KYC/KYB — submit the business registration, optionally add hosted ID verification for signing members, and poll the status endpoint until the org is approved. Regulated channels then reuse that verified packet as a compliance profile instead of re-uploading documents per registration; the compliance profiles guide shows which profile shape each surface (RCS, WhatsApp, alphabetic Sender ID) opens with. For alphabetic Sender IDs specifically, run the Sender-ID country matrix before you choose launch markets: it separates markets that force pre-registration (file before your first send) from markets where a dynamic sender works outright — the lead time differs by weeks.

​

4. Campaign-draft path — filing content, not identity

A paused campaign stays incomplete until the campaign object itself is filed with the market’s registry. In the US that is a 10DLC campaign declaration; in India it is a DLT template; both follow the same draft → preflight → submit loop as the 10DLC registration guide describes for TCR. When the campaign targets US toll-free numbers, add toll-free verification (TFV) on top of the brand and campaign filings — the TFV guide lints sample content before you submit the carrier form, which removes the most common rejections. Either filing alone leaves the draft incomplete in a regulated market; check the destination’s rules on the country requirements before you assume one registration covers all traffic classes.

​

5. Worked example — the person path done end to end

A physical therapist texting appointment reminders to US patients from one long code. Her class row is person; the signature she is looking for is a wizard that reads ready and a timeline with no open 10DLC rows.

1. Start the 10DLC wizard and save the brand section with entity_type: SOLE_PROPRIETOR, a display name, and her personal mobile as brand.phone. Sole-proprietor brands substitute a verified phone for an EIN — she runs the OTP pair (POST /10dlc/wizard/phone/send → /phone/confirm) until the confirm response reads "status": "verified". The proof keys to the exact phone string: editing brand.phone afterwards voids it and submit refuses with 422.
2. Fill the campaign section in the same draft: usecase + description, sample messages, the opt-in message flow, and STOP/HELP copy. The progress payload (GET /10dlc/wizard) reports which fields are still missing, so she can save partial work across sessions.
3. Lint, then atomically submit. POST /10dlc/wizard/preflight scores the persisted draft against known TCR rejection patterns; she fixes findings until the verdict passes, then POST /10dlc/wizard/submit files brand and campaign in one call. The response stamps the TCR identifiers — "brand_id": "B…", "campaign_id": "C…" — with state: "brand_pending". Brand vetting typically lands in 1–48 hours; the campaign follows the brand.
4. Wait for the approval signature. She polls GET /10dlc/wizard until state flips to ready — the wizard’s done-state, reached only when both the brand and the campaign come back APPROVED from carrier review. The per-carrier detail lives on GET /10dlc/campaigns/:id/status: the top-level status is the CSP-level decision, and mnoStatuses maps each carrier (T-Mobile, AT&T, Verizon) to its own APPROVED / REVIEW verdict — approvals land carrier by carrier, as the 10DLC registration guide lays out.
5. Assign the number into the campaign. An approved campaign with no assigned numbers still sends at unregistered-10DLC rates, so the number assignment is part of “done,” not an afterthought. Then she gives the sender a reusable container: an SMS sending service bundles the approved number, its STOP/HELP opt-out list, and the inbound webhook; if she later spreads volume across several approved numbers, sender pools rotate between them under the same registration.

Done-state checks — the platform now shows:

• The wizard progress payload returns state: "ready" — the end-user can see it without touching the API, because the same payload drives the dashboard’s “continue where you left off” banner.
• Settings → Onboarding status (the Verifications timeline) shows both the 10DLC brand row and the campaign row Approved, with 0 pending, 0 rejected on the counts strip — that strip, not “submitted,” is the launch-readiness threshold.
• GET /10dlc/campaigns/:id/status returns the CSP-level status: "APPROVED"; the number is assigned to that campaign id.

​

6. Worked example — the org brand path done end to end

A logistics company launching alphabetic Sender-ID SMS to the UAE and Saudi Arabia. Its class row is org brand; the signatures it is looking for are an approved KYC verdict and one approved Sender-ID registration per required market.

1. File organization KYC — the business registration plus company details, submitted once. The organization polls GET /api/v1/organization/kyc/status until it reads approved; that verified packet is what regulated channels reuse instead of re-uploading documents per registration.
2. Assemble the compliance profile on top of the KYC packet. Profiles follow draft → pending_review → approved and are graded against each destination’s country rules — only an approved profile opens the surfaces below.
3. Check the launch markets in the Sender-ID country matrix before committing to them. For the UAE, GET /api/v1/compliance/country-rules?channel=sms returns the country row with registration: "required" — TDRA expects a KYC-backed brand identity attached to the sender name. A required value means the send gate blocks A2P traffic to that destination (a 422 with a market-specific code) until the registration is approved, so the lead time is part of the launch plan.
4. File the Sender-ID registrations against the approved profile, one per destination, and wait for each to reach approved. In the dashboard, Settings → Compliance → Sender IDs lists every alphabetic sender the tenant has filed with its per-country registration state; a healthy console shows the sender name with an approved registration for every required market in the launch plan. The page the approval lands on is the same page the send gate consults at send time.

Done-state checks — the platform now shows:

• Settings → Onboarding status (the Verifications timeline) shows the Account (KYC) row Approved and one approved row per destination-country profile, with a Resolve link on anything still open.
• Settings → Compliance → Sender IDs reads the sender name as approved for each launch market — for a required destination, that approved row is the difference between a send and a 422.
• From then on, a send to the gated destination passes the sender-identity gate instead of returning 422 — the matrix page documents the MESSAGING_*_SENDER_NOT_REGISTERED codes the gate emits until then.

​

7. Worked example — the campaign-draft path done end to end

A healthcare network running medication reminders on one US toll-free number. Its class row is campaign draft — the brand identity is already filed; what is outstanding is the content filing — plus a toll-free verification, because the sender is an 8XX number.

1. Register the brand and campaign as a 10DLC filing if long codes are in scope, or the DLT template for India — the same draft → preflight → submit loop either way. The campaign declaration is the use case a carrier grades; the 10DLC marketing baseline covers what acceptable sample content looks like before it goes in.
2. Layer toll-free verification on the 8XX number. The TFV guide lints the sample messages first — the linter returns ok: false with severity-tagged findings for the patterns carriers reject (missing opt-out wording, regulated verticals) — then submits the use-case form. The number’s tfvStatus flips to pending; carrier review takes days, and Orbit polls the carrier in the background until the verdict lands. A successful track loop ends at tfvStatus: "approved" with tfvApprovedAt set — approved is terminal (re-filing returns 409), and the messaging restrictions on the number lift.
3. Prove the campaign object against the filed pair. On the campaign end-to-end guide’s flow, create the draft with the message_template, attach the audience, then run POST /api/v1/campaigns/:id/dry-run. The dry-run is read-only and is exactly where an unfiled campaign surfaces: the channel’s warnings[] report a sender with missing registration instead of failing at send time, while a clean run returns warnings: [] with cost.sufficient: true — that green shape is what a launch (POST /campaigns/:id/send) re-checks.

Done-state checks — the platform now shows:

• Settings → Onboarding status (the Verifications timeline) shows the 10DLC campaign row Approved and the toll-free number’s phone-number row Approved — the timeline carries one row per DID waiting on verification.
• The toll-free inventory reads tfvStatus: "approved" on the number, and an attempt to re-file returns 409 because approval is terminal.
• The campaign dry-run returns warnings: []; with the audience cohort and wallet checks green, nothing sender-side stands between the draft and launch.

​

8. Ready-to-send pivot — the final gate

Registration completeness is a carrier/registry question; the send gates — wallet posture, opt-out sync, quiet hours, frequency caps — are yours to walk afterward, and most of them are tenant-owned controls you configure, not platform defaults. Run the pre-flight checklist once your registration row above reads complete: it is the final admission check for every outbound blast, voice broadcast, or API send, for senders of every class.