​

Route a first-time channel connect to the right onboarding surface

The first-channel guide is the general picker: it covers the shared shape every channel follows (Messages hub → Connect → send → verify) and holds SMS and WhatsApp as the worked examples. Four first-channel picks, though, have dedicated single-surface runbooks, and starting from the picker when one of these is your target adds a detour. This page routes you.

​

1. The decision: picker or surface runbook

For each of the four most common first picks, one question decides which door to open: If your pick is not one of these four, stay on the picker — SMS, RCS, Telegram, and outbound email all flow through it cleanly.

​

2. Per-surface runbook pointer

Each runbook differs from the picker on one specific scope line. The notes below tell you what the runbook covers, what breaks when you skip it, and what to have ready before you open it.

​

Native chat widget — channel configuration guide

What the runbook covers. The Settings → Channels → Native Chat surface: brand color, position, agent identity, business hours, GDPR consent, and origin locking, then the two install-snippet forms (a <script> tag or a dynamic JS loader) you paste into your site. It also explains the rule that console values override constructor options passed to OrbitChat in code. Worked example. The runbook ends with a verifiable embed: copy your widget ID from the Install snippet tab, paste one of the two snippet forms into your site, and the widget renders on next page load. What breaks if you skip it. A snippet embedded with a hard-coded greeting or position fights with whatever operators later set in the console — the console wins, so fielded defaults without the console pass ship a widget whose copy and placement nobody on the team can explain. Worse, a widget embedded without the Enable widget toggle flipped in the console renders nothing for visitors regardless of what code you shipped. Before you start.

• Can edit the pages where the widget will appear (or hand the snippet to whoever can)
• Know which site domains you host on — the origin-locking step needs the list
• (Optional but fastest) Validate the snippet on a staging page against the sandbox and test mode guide before exposing it to visitors

​

Inbound email parse — inbound email and SMS routing guide

What the runbook covers. The inbound direction that the picker never touches: domain-based email parse (MX records pointed at Orbit, typically a dedicated subdomain), the normalized inbound payload shape, attachment archival and quarantine, match rules for inbound SMS, keyword auto-replies via Flows, and bounce/unsubscribe handling. Worked example. The MX-post subdomain (inbound.your-domain.com) goes live, an inbound message lands on the normalized webhook payload, and a match rule routes it to the right team or Flow. What breaks if you skip it. Inbound traffic with no route rule is ingested but dead-ends — customers write to you, nothing answers, and the first sign is a complaint, not a log line. Inbound route management endpoints also reject member-role API keys with 403, so an integrator armed with the wrong key burns their first afternoon on permission errors before the DNS even propagates. Before you start.

• An owner- or admin-role API key (dv_live_sk_… — member keys get 403 on the route CRUD calls)
• DNS access to point MX records (email), or an inbound-capable number on the account (SMS)
• A public HTTPS endpoint ready to receive forwarded webhooks
• Read the sandbox and test mode guide to rehearse inbound injection (POST /api/v1/sandbox/inbound) before touching a live domain

​

WhatsApp Business API — WABA setup runbook

What the runbook covers. The full production path: Meta Business Manager verification, choosing a new vs. migrated number, the embedded signup, number verification (SMS or voice code), display name and profile, template submission, and the go-live gates — a ~3–7 business-day sequence when documents are in order. Worked example. Business documents uploaded to Meta match the legal entity, the display name passes review, the first template is approved, and the number is ready to send under the daily-tier limits the runbook explains. What breaks if you skip it. Meta rejects the verification and the clock resets — a placeholder website, a display name that differs from the legal documents, or a certificate-of-incorporation mismatch each push the timeline back by days. Teams that skipped the checklist discover this after their launch date is already committed. Until business verification completes, the account is also capped at 250 unique recipients per 24 hours, so a skip is a throughput cap as well as a schedule slip. Before you start.

• Certificate of incorporation, tax ID, and proof of address matching the legal entity name
• A live website with real content and a visible privacy policy (“Coming Soon” pages and Notion links are rejected)
• A phone number that can receive an SMS or voice verification call
• For a pure smoke test before documents are ready, run the sandbox path in the picker instead — the sandbox guide explains the test-key flow

​

Push — push integration guide

What the runbook covers. The library/SDK connect, because push has no Messages-hub card: token registration (browser VAPID via the Web SDK, APNs/FCM via the mobile SDKs), targeting users vs. broadcast, per-device delivery results, scheduled sends, and push.delivered / push.opened engagement acks that close the loop. Worked example. A device registers its token on first run, a targeted send returns per-device results you can read token by token, and the engagement acks confirm delivery and opens in your webhook handler. What breaks if you skip it. Every send returns NO_DEVICE_TOKENS until a device registers, so a team that went straight to the send API sees a wall of failures with no obvious cause. And because there is no dashboard “Connect” card to glance at, the only signal that push is working comes from the per-device result payloads and engagement acks the runbook teaches you to read. Before you start.

• The Web SDK for browser push, or the Android/iOS SDK for APNs/FCM
• A public API key (dv_live_pk_…) for client-side registration calls
• Provider credentials where required (FCM server key, APNs certificate, or VAPID pair — the push channel page covers setup)
• The sandbox guide so test registrations never hit real devices

​

3. Anchor map

The four runbook pages above are complete onboarding paths; the first-channel picker remains the authoritative guide for overall channel strategy — which channel to pick, how the connect → send → verify shape holds across channels, and how to hand off between channels. This page is only the router from that strategy decision to the correct surface runbook; it grants no other page authority over the pick. For sandbox-first validation of any pick, the sandbox and test mode guide covers the simulated surface both doors feed into.

​

How to know you picked the right runbook

Check yourself against these four tests before investing in a runbook:

• You opened the picker and the Messages hub shows no Connect card for your channel. Push is the classic case: a missing card routes you to the SDK-based push runbook, not a misconfigured tenant.
• The picker’s numbered steps feel like the wrong direction. If every step is about sending and your task is receiving (inbound email, inbound SMS), you belong in the inbound parse runbook.
• Your timeline fits inside the picker. SMS, RCS, Telegram, and outbound email onboarding takes minutes and the picker covers it — if your channel adds a multi-day vendor-verification gate (Meta WABA review), that gate has its own runbook.
• Your “channel” is your own web property. A chat widget embedded on your site is configured on the Native Chat console page, not connected like a carrier.

Correctly routed? Onboard, then move to the go-live checklist — the production gates apply to whichever surface you picked.

​

Next steps

• Connect your first channel — the general picker this page routes from
• WhatsApp getting started — broader WhatsApp surface beyond WABA setup
• Go-live checklist — production gates after whichever surface you onboarded