Verifications Timeline

Some channels can’t carry live traffic until a verification step clears: account KYC unlocks live mode, 10DLC registration unlocks US SMS throughput, and a per-country compliance profile unlocks phone numbers in regulated markets. Before this page, each of those reviews was a black box — you submitted and waited. Settings → Onboarding status renders every verification step your workspace has started as one vertical timeline. Each row shows its current state, who is reviewing it (Devotel or a carrier), the expected resolution time where a published SLA exists, the specific blocker, and a Resolve link that jumps straight to the page that fixes it. A counts strip above the list totals how many steps are approved, in review, rejected, or pending, so you can see launch readiness at a glance.

Step states

Each timeline row falls into one of five states:

State	What it means
Pending	The step is a draft — started but not submitted for review. Submit it to start the clock.
In review	Submitted and with a reviewer. For long-running reviews the row also shows how long ago you submitted.
Approved	The review passed. The Resolve link becomes a View link back to the completed step.
Rejected	The reviewer declined the step. The blocker text names the rejection reason; use Resolve to open the form, correct it, and resubmit.
Not applicable	The step doesn’t apply to your workspace (for example, no US SMS traffic means no 10DLC row is required).

States are color-coded, and an in review row carries a subtle pulsing marker so active work draws your eye.

Step kinds

The timeline aggregates five kinds of verification step, each labelled with its kind:

Account — account-level KYC. Reviewed by Devotel; this is the hard gate on live-mode sending.
10DLC — one row for your brand registration and one per campaign. Reviewed by carriers through The Campaign Registry (TCR).
Country — per-country compliance profiles, one row per country you’ve profiled (see KYC documents & compliance profiles).
Phone number — one row per DID waiting on a compliance profile. A number that shows “profile attached” still can’t carry traffic until its profile is approved.

If the page is empty, start with account verification (KYC) — the empty state links directly to it.

Reading the ETA line

The ETA line appears only when the underlying step has a published resolution window — the dashboard never invents a deadline it can’t keep:

A pending row with an SLA shows the promised window (for example, “Review SLA · usually < 24h”) so you know the committed review time before you submit. Today, account KYC is the only step with a published SLA.
An in review row with an SLA shows a concrete ETA derived from your submission time (for example, “ETA Wed 3:14 PM”) when the timestamp was recorded, or the SLA label otherwise.
Carrier-reviewed steps (10DLC, country profiles, phone numbers) depend on third-party registries and carriers, so they show no ETA.

In-review rows also show a “Submitted Nh ago” line when a submission timestamp exists.

From the timeline to the fix

Every row ends in a Resolve link to the exact page that clears its blocker:

Account KYC → Settings → KYC
10DLC brand or campaign → Settings → Compliance → Sender IDs
Country profile → Settings → Compliance → Profiles (the specific profile)
Phone number → Settings → Compliance → Profiles — the attached profile, or the profiles list when none is attached yet

Channel-specific provisioning — the WhatsApp Business Account (WABA) connection, RCS agent registration, and voice campaigns — has its own setup surfaces under Channels and Settings → Channels. Use this timeline for KYC and carrier compliance gates; it is the checklist for everything that gates live sending.

Use it as a launch checklist

When you’re launching against a deadline, open the timeline first:

Start with the Account (KYC) row — its published SLA (usually under 24 hours) makes it the only verification step you can schedule against a hard deadline with confidence. Submit KYC before anything carrier-side.
Submit every Pending row. A pending step blocks launch as hard as a rejected one; the SLA clock only starts at submission.
Work Rejected rows top-down — the blocker line names the exact reason (a missing tax ID, an opt-out wording gap), so Resolve lands you on the right form without a support round-trip.
Judge readiness from the counts strip — 0 pending, 0 rejected is your launch-readiness threshold, not “everything shows approved.”

See Production go-live checklist for the full launch pass (API keys, webhooks, billing, guardrails) beyond verification steps.

Where each step’s controls live

The verification steps roll up from the tenant-owned compliance controls you configure elsewhere — the timeline aggregates them; it doesn’t own them:

KYC documents and structured compliance profiles are created and maintained under Settings → Compliance → Documents / Profiles — see KYC documents & the compliance-profile lifecycle.
The broader getting-started sequence (verify email, add a payment method, first message, and so on) lives on the dashboard Home checklist and the Quickstart — the timeline only joins in once a review-type step exists.
10DLC specifics (brand vetting, campaign use cases, throughput expectations) are covered in 10DLC registration; Country requirements lists the per-country profile fields.

Rejections, approvals, and resubmissions are recorded in Settings → Audit log, so the timeline’s history is traceable across your team.

Read the status API

Everything this page renders comes from one aggregate endpoint, GET /api/v1/onboarding/status-timeline — the same read the dashboard makes. Poll it yourself when you want the verification posture inside an internal status board, a launch-readiness gate in CI, or a support escalation with a concrete request id.

curl
Node.js (SDK escape hatch)
Python (SDK escape hatch)

curl "https://api.orbit.devotel.io/api/v1/onboarding/status-timeline" \
  -H "X-API-Key: dv_live_sk_your_key_here"

// The typed SDK has no onboarding-status helper, so go through the
// generic escape hatch — same X-API-Key auth, same { data, meta } envelope.
import { Orbit } from "@devotel-orbit/node";

const orbit = new Orbit({ apiKey: process.env.ORBIT_API_KEY });

const { data } = await orbit.request("GET", "/onboarding/status-timeline");
for (const step of data.steps) {
  // step.resolveUrl deep-links a teammate straight to the form that
  // unblocks the row; step.sla/etaAt are null rather than fabricated
  // when the underlying review publishes no window.
  console.log(step.id, step.state, step.blocker, step.resolveUrl);
}

# Same escape-hatch shape on the Python SDK.
from orbit_sdk import OrbitClient

client = OrbitClient.from_env()  # reads ORBIT_API_KEY

timeline = client.request("GET", "/onboarding/status-timeline")
for step in timeline["data"]["steps"]:
    print(step["id"], step["state"], step["blocker"], step["resolveUrl"])

The 200 response carries the rows the dashboard renders, in the standard { data, meta } envelope:

{
  "data": {
    "steps": [
      {
        "id": "kyc:account",
        "kind": "account_kyc",
        "label": "Account verification (KYC)",
        "state": "in_review",
        "updatedAt": "2026-09-24T09:41:00.000Z",
        "submittedAt": "2026-09-23T14:12:00.000Z",
        "sla": { "hours": 24, "label": "usually < 24h" },
        "etaAt": "2026-09-24T14:12:00.000Z",
        "blocker": "KYC submitted — Devotel review in progress.",
        "resolveUrl": "/settings/kyc",
        "reviewer": "Devotel review"
      },
      {
        "id": "brand:brand_3f2a9c",
        "kind": "ten_dlc_brand",
        "label": "10DLC Brand — Acme Logistics",
        "state": "rejected",
        "updatedAt": "2026-09-24T08:02:00.000Z",
        "submittedAt": "2026-09-22T15:01:00.000Z",
        "sla": null,
        "etaAt": null,
        "blocker": "TCR rejected the brand: EIN does not match the legal name.",
        "resolveUrl": "/settings/compliance/sender-ids",
        "reviewer": "Carrier review (TCR)"
      },
      {
        "id": "did:num_5c1aa2",
        "kind": "per_did",
        "label": "Phone number +1 415 555 0123 (US)",
        "state": "in_review",
        "updatedAt": "2026-09-24T07:30:00.000Z",
        "submittedAt": "2026-09-24T07:30:00.000Z",
        "sla": null,
        "etaAt": null,
        "blocker": "Awaiting carrier verification of the attached compliance profile.",
        "resolveUrl": "/settings/compliance/profiles/cprof_7d41bb",
        "reviewer": "Carrier review"
      }
    ],
    "counts": {
      "total": 3,
      "approved": 0,
      "in_review": 2,
      "rejected": 1,
      "pending": 0
    },
    "computedAt": "2026-09-24T10:04:01.000Z"
  },
  "meta": {
    "request_id": "req_7c2e9604",
    "timestamp": "2026-09-24T10:04:01.000Z"
  }
}

Field mapping to the page above: state is the row’s state chip (pending / in_review / approved / rejected / not_applicable); reviewer is the who-is-reviewing line (Devotel review on the account step, Carrier review on carrier-side steps); sla + etaAt are the ETA line — sla.hours plus a label when a committed window exists, etaAt the concrete submittedAt + sla.hours timestamp, both null when the underlying review publishes no window; blocker is the blocker text (null when there is nothing to act on); resolveUrl is the Resolve link’s target. data.counts feeds the totals strip, and meta.request_id is the id to quote when you file through support. The aggregate is cached 60 seconds per organization, so poll at or above that cadence — a step aging past its etaAt is a signal to act, not a reason to re-fetch faster.

Role-gating errors

The endpoint is read-only and org-scoped: any workspace API key or signed-in dashboard member can read it, and the rows always describe the organization the credential belongs to. Two envelopes gate it:

{
  "error": {
    "code": "UNAUTHORIZED",
    "message": "Authentication required. Provide X-API-Key or sign in via Clerk.",
    "status": 401
  }
}

401 — no usable credential on the request. Send a workspace secret key (dv_live_sk_…) in the X-API-Key header (or as Authorization: Bearer dv_live_sk_… where a proxy blocks the custom header).

{
  "error": {
    "code": "WRONG_KEY_MODE",
    "message": "This API key is live-mode but the workspace is the sandbox sibling. Switch to your sandbox key in Settings → API Keys.",
    "status": 403
  }
}

403 — the key is valid but gated: either its mode disagrees with the workspace (WRONG_KEY_MODE — a live key on the sandbox sibling or vice versa; swap keys under Settings → API Keys) or your key has an IP allowlist and the caller’s address is not on it (IP_NOT_ALLOWED). Mint the key inside the workspace whose timeline you are reading — the aggregate is scoped to the key’s own organization, so a key from another workspace always returns that workspace’s rows, not this one’s.

WhatsApp

Developer console

Contact center

Guides

Messaging Controls

Audience & Support Tools

Read the Verifications timeline — every KYC and carrier step, its ETA, and its blocker

Verifications Timeline

Step states

Step kinds

Reading the ETA line

From the timeline to the fix

Use it as a launch checklist

Where each step’s controls live

Read the status API

Role-gating errors

​Verifications Timeline

​Step states

​Step kinds

​Reading the ETA line

​From the timeline to the fix

​Use it as a launch checklist

​Where each step’s controls live

​Read the status API

​Role-gating errors

​Related pages

Verifications Timeline

Step states

Step kinds

Reading the ETA line

From the timeline to the fix

Use it as a launch checklist

Where each step’s controls live

Read the status API

Role-gating errors

Related pages