Skip to main content

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: 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 — 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 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 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; 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.