Skip to main content

​
Production Go-Live Checklist

The Quickstart Step 5 names the two hard gates on live traffic (KYC approval and a funded balance). This checklist gathers the rest — live keys, number readiness, webhooks, guardrails, security, and compliance — into one page you can walk through with your team before you launch. Assign an owner to every checkbox before you start. The launch sign-off below means the named owner confirmed it, not just “someone checked.”

​
1. Sandbox sign-off

Prove your integration end-to-end in sandbox before you touch live traffic.
  • Sandbox sends succeed on every channel you’ll use. Run SMS, WhatsApp, email, and/or voice with your dv_test_sk_ key. Owner: Engineering.
  • Failure paths are covered with sandbox magic numbers. Trigger the undelivered, expired, and carrier-rejection receipts your retry logic must handle. Owner: Engineering.
  • A delivery webhook receives and records sandbox receipts. Handle duplicates (Orbit may retry) and ignore out-of-order statuses you don’t care about. Owner: Engineering.
  • Your sending code reads the key mode from configuration. The same request shape works for dv_test_sk_ and dv_live_sk_; confirm nothing hard-codes the sandbox key. Owner: Engineering.

​
2. Live API keys

Move production traffic onto live keys with a rotation and access plan.
  • KYC is approved and the balance is funded. These two unlock live sending; both are required for SMS, WhatsApp, and voice. Owner: Operations.
  • A live secret key (dv_live_sk_) was minted under Settings → API Keys for each service that sends. Store it in a secret manager; never in the repo or client-side code. A leaked key is revoked and re-minted. Owner: Engineering.
  • Key rotation is a routine operation, not a scramble. Rotate on a schedule and on any live-key leak. Owner: Engineering.
  • An IP allowlist is configured for live keys. Limit which source IPs may use your live credentials — see API key IP allowlist. Owner: Engineering.

​
3. Number and sender readiness

Make sure the sending identity you’ll use is actually live-capable.
  • Your messaging numbers are SMS-capable. If you use WhatsApp, the sender bound to a WhatsApp Business profile (WABA) is ready. Owner: Operations.
  • 10DLC brand + campaign are registered for US A2P SMS. Required before US SMS sends on live traffic — see 10DLC registration. Layered on top of KYC, not an alternative to it. Owner: Compliance/Operations.
  • TFV (toll-free verification) and/or CNAM are in place where relevant. CNAM affects caller-ID display for voice; TFV affects toll-free SMS deliverability. Numbers pages: CNAM, emergency address. Owner: Compliance/Operations.

​
4. Webhooks

Live traffic needs a production webhook endpoint, not just a test tunnel.
  • The endpoint is served over HTTPS with a valid certificate. HTTP-only endpoints are rejected. Owner: Engineering.
  • Signature verification is in place. Verify X-Orbit-Signature (and fall back to the legacy X-Devotel-Signature) against your signing secret; reject missing/mismatching signatures — see webhook security. Owner: Engineering.
  • Replay protection rejects deliveries with timestamps older than five minutes. The t= value lives in the same signature header. Owner: Engineering.
  • Your inbound firewall allows the webhook egress IPs Orbit publishes. Fetch the current list from GET /api/v1/webhooks/egress-ips, then allowlist it on your receiver — see webhook security. Owner: Engineering.
  • Dead-letter / replay handling is designed. Acknowledge quickly, process asynchronously, and tolerate retries. Owner: Engineering.

​
5. Sending guardrails

Decide how your traffic resists mistakes before a campaign goes out.
  • Opt-out lists are configured. STOP and related keywords flow into a list your send path checks. Owner: Operations.
  • Frequency caps match your use case. Marketing traffic gets recipient-facing caps; system traffic gets coherent limits. Owner: Operations.
  • Message suppression covers the scopes you need. Hard blocks stay durable across channels. Owner: Operations.
  • The sandbox-impersonation guard can’t trip. Production sends must come from a key whose mode matches the organization’s environment — a dv_test_sk_ key on a live environment returns WRONG_KEY_MODE. Owner: Engineering.
  • DNC and related send gates are wired where required. Quiet hours, DNC/RND/RMD scrub, and emergency stop live under Compliance → Send Gates. Owner: Compliance.

​
6. Wallets and billing

Live traffic debits a real balance; avoid surprise stalls.
  • The wallet has enough funded balance for launch volume plus headroom. Owner: Operations/Finance.
  • Per-feature budgets cap the campaigns and agents you run. Owner: Operations/Finance.
  • Low-balance and spend alerts reach the on-call owner. A funded balance is a requirement for SMS, WhatsApp, and voice sends. Owner: Operations/Finance.

​
7. Security posture

Review account access and auditability before customers and agents touch the workspace.
  • Member roles are assigned from least-privilege. Owner/admin for administration; developer for API + webhooks; viewer for read-only; billing-only where possible. See security. Owner: Administrator.
  • SSO is enforced if your organization uses an identity provider. Owner: Administrator.
  • The audit log has been reviewed since the last launch. Look for unexpected key creation, member changes, or sender changes. See security. Owner: Administrator.

​
8. Compliance readiness

Compliance gates differ by country and channel; pre-clear them before launch.
  • An emergency address is on file for voice numbers where the jurisdiction requires it. See emergency calling. Owner: Compliance.
  • Country requirements are documented for every destination you send to. Country requirements list per-country rules. Owner: Compliance.
  • Your 10DLC brand and campaign statuses are approved. Not merely submitted. See 10DLC registration. Owner: Compliance.
  • DNC scrub and opt-out handling are active and stay active. Quiet hours and register scrubs live under send gates. Owner: Compliance.

​
9. Ops — observability, rollback, and launch pacing

Be able to see failures and retreat if something goes wrong.
  • Dashboards / monitors track failed deliveries, and alerts go to a working inbox. Failed-delivery spikes usually mean the sender, content filter, or number pool. Owner: Operations.
  • Audit logs are reviewed as part of your incident routine. Owner: Administrator.
  • A rollback path is documented and reachable. A feature flag, a previous sender, or a stop valve on the campaign entry point. Owner: Engineering.
  • Rate limits you’ve factored into launch throughput are within quota — or raised in advance. Rate limits are enforced per API key; request a per-organization override from support if needed. Owner: Operations.
  • Canary steps are planned. Launch to a small audience, watch failures for a defined window, then widen. Owner: Operations.

​
Launch-day timeline

A short sequence teams typically follow. Adjust the windows to your traffic:
  1. T-24 h — sign-off. An owner initialises every checkbox above; engineering freezes senders, keys, and webhooks.
  2. T-1 h — final checks. Re-confirm KYC approved, wallet funded, webhook endpoint live, and 10DLC approved.
  3. T-0 — canary. Send a small live batch (or place a small call set) and watch delivery events for the canary window.
  4. T+1 h — widen. If failures stay inside the alert threshold, expand to the full audience.
  5. Post-launch — keep watching. Failed-delivery rate, wallet balance, and alert inboxes stay monitored through the first day.