> ## 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. # Onboarding status timeline > Watch every verification gate — account KYC, 10DLC brand and campaign, per-country sender profile, per-number registration — from one Settings page, with the current blocker, reviewer ETA, and a one-click resolve link on each step. # Onboarding status timeline Go-live is not one review — it is a stack of them. Account KYC approves the business, 10DLC registers the US sender brand and campaign, country sender profiles clear regulated markets, and some carriers vet each phone number individually. **Settings → Onboarding Status** aggregates all of them into one vertical timeline, so you see every gate you have started, who is reviewing it, the expected resolution time, and exactly what is blocking it. This page walks the timeline top to bottom: what it shows, what each state means, how the resolve link works, where the ETA comes from, and what to do when a step outruns its estimate. *** ## 1. What the timeline shows Each row on the timeline is one verification step you have started, in one of five step types: * **Account** — organization KYC/KYB for the business itself. * **10DLC** — each registered brand and each campaign under it (US A2P messaging). * **Country** — a per-country sender profile required by a regulated destination. * **Phone number** — per-number (per-DID) registration where a carrier asks for it. Every row carries a state chip, a reviewer line (Devotel operations review or carrier review, depending on the step type), the current blocker in plain words, a resolve link, and — when one exists — the review SLA or a concrete ETA. A counts strip at the top totals the steps by state, and a refresh button re-polls the aggregate; the server caches the read for 60 seconds, so refreshing is cheap. Steps you have never started do not appear — the page does not try to predict your go-live path, it reports the gates you actually opened. ## 2. Where to find it Open **Settings → Onboarding Status** in the dashboard. The page is a read-only aggregation over the same verification state the individual section pages (KYC, 10DLC, compliance profiles, numbers) manage — nothing you do here creates a step; it collects them. The same aggregate is also available over the API at `GET /api/v1/onboarding/status-timeline`, for teams that want the org's verification posture inside an internal status board instead of the dashboard. ## 3. Step states, and the current blocker A step is always in one of five states: | State | Meaning | | ------------------ | -------------------------------------------------------------------------------------------------- | | **Pending** | Started but not yet submitted to the reviewer — usually the form is incomplete. | | **In review** | Submitted; a Devotel operations or carrier reviewer has it. The timeline dot pulses on this state. | | **Approved** | The gate is green. | | **Rejected** | The reviewer declined it; the blocker line names the gap and the resolve link reopens the form. | | **Not applicable** | The gate no longer applies (e.g. the destination profile was removed). | The **blocker** line is the one thing standing between the step and approval — "Missing EIN", "Awaiting carrier verification", "Campaign suspended by registry", and similar. It comes from the same underlying status each section page shows, condensed so the timeline stays scannable. For **In review** steps the row also shows how long ago you submitted ("Submitted 4h ago"), so an aging review is visible at a glance. ## 4. One-click resolve Every row ends in a link: **Resolve** for anything not yet approved, **View** once approved. Resolve deep-links to the page that can actually move the step — the KYC form for account steps, the 10DLC wizard for brand/campaign steps, the compliance-profile editor for country profiles, the number's detail page for per-DID steps. Fix the flagged field there, resubmit, and the timeline flips the step back to **In review** on the next refresh. Because resolve is a deep link, it is also shareable: paste a row's resolve URL to a teammate and they land on the exact form that unblocks the step. ## 5. Where the ETA comes from — SLA vs prediction The timeline never invents a deadline. Two sources feed the ETA line, and only these two: 1. **A documented review SLA.** When the underlying review defines a committed window (today, account KYC publishes "usually \< 24h"), a **Pending** step shows that SLA as a forward-looking promise, and an **In review** step shows it as the expected window until a concrete ETA supersedes it. 2. **A concrete reviewer ETA.** When the reviewer's queue stamps an expected decision time, the row shows it as a human-readable timestamp ("ETA Wed 3:14 PM"). When neither source exists — the common case for carrier-side steps like 10DLC campaign vetting, whose queues publish no SLA — the row shows **no ETA line at all**, rather than a fabricated guess. Carrier-facing steps are the ones most likely to surface a bare "in review" with only the submitted-ago line; that is the honest read of a queue the platform cannot time. ## 6. Stuck past the ETA? Work the neighbor guides A step that outruns its published SLA or concrete ETA is actionable, not a waiting posture: * For **Account (KYC)** steps, work the [organization KYC onboarding guide](/guides/organization-kyc-onboarding) — it covers resubmission, the business-screening signal, rejection handling, and how support re-opens a file. * For **Phone number** steps stuck in a carrier review, check [number provisioning failures](/troubleshooting/numbers-provisioning-failed) before assuming the queue is merely slow — a provisioning error surfaces on the number's own page first. * For **10DLC brand/campaign** rejections, the [10DLC rejections guide](/guides/10dlc-rejections-and-revet) maps registry rejection codes to fixes. If the SLA expired with no verdict and none of the above applies, file through support with the step's step-type and the request id from a `GET /api/v1/onboarding/status-timeline` poll so the review queue owner can locate the file. ## 7. Timeline step ↔ webhook events The timeline is a **read surface over the same state your webhooks receive** — it never creates state of its own. When a reviewer decides, two things happen in parallel: the step's state flips on this page, and the platform dispatches the corresponding event to any subscribed endpoint. Use the page for humans and webhook subscriptions for automation: * Account-KYC decisions appear in the notification stream as `kyc_decision` (an in-app/email notification kind), so ops teams get the verdict without polling this page. * A suspended 10DLC campaign fires `compliance.10dlc.campaign.suspended`, which flips the campaign's timeline step to a blocker — subscribe to it to pause sends automatically instead of learning about the suspension from the dashboard. * The full subscribable catalog lives in [Webhook Events](/webhooks/events); wire whichever verification-adjacent events your operation needs, and let the timeline remain the human-side view of the same gates. Either way, the page and the events describe one timeline — resolve on the page clears the same blocker your webhook consumer saw.