A launch that skips the sandbox is a bet that nothing will go wrong. The CPaaS sandbox exists so that bet doesn't have to be made: simulate SMS and voice traffic end-to-end, exercise every delivery state a carrier can fire, and check go-live readiness on a checklist — before a single real message or call is sent. This guide walks the Orbit sandbox from first test key to launch-day checklist, so the integration going live is the one you already verified works.
Quick answer: On Devotel Orbit, mint a test API key (prefixed dv_test_sk_), run sends against the magic-number test table (each trailing digit triggers a different delivery state), use the sandbox state-control endpoints to reset or scaffold fixtures, and check the shared pre-launch checklist at GET /sandbox/pre-launch-checklist before flipping to live keys.
Why a sandbox matters for messaging and voice
Production traffic carries consequences a test environment never will: a misconfigured opt-out gate blocks real recipients, a wrong webhook URL pages your on-call at 3 a.m., and an unverified E911 registration dispatch is a safety issue, not a bug. A sandbox that mirrors production — same APIs, same delivery-receipt shapes, same error taxonomy — lets you find those on the test bench, where the cost of a mistake is a log line, not a customer incident.
The key word is mirrors. A sandbox that accepts anything and always answers "delivered" teaches nothing; the integration gets promoted to production and the first real carrier reject becomes the first thing you ever tested. Orbit's sandbox is built to fail the same ways production fails.
The Devotel Orbit sandbox surface
Orbit's sandbox has four moving parts, each answering a different launch question:
- Test API keys. Keys minted from Settings → API Keys with the
dv_test_sk_(secret) ordv_test_pk_(public) prefix carry their own rate limits and can never resolve a live org — a live credential can't accidentally hit the sandbox either. The MCP tooling and checkout integrations accept the same prefix, so a staging assistant runs sandbox traffic by construction. - A paired sandbox organization. Every live product org gets a sandbox sibling workspace, paired so the dashboard and checklist know which two are linked. Test data, fixture numbers, and experiments live in the sandbox sibling; the live org stays clean and is never mutation-eligible from a sandbox route.
- Deterministic magic numbers.
GET /sandbox/numbersreturns a fixed baked-in test table — ten delivery states, one per trailing digit — so a SMS send to a magic number reproduces a specific carrier outcome every time, fromdeliveredthroughblocked(suppression hit) andunknown(carrier never reported a final state). The digit is deterministic; you can assert on it in a CI test. - State-control endpoints. Three mutation routes reset the sandbox to a clean slate (
POST /sandbox/reset), provision deterministic fictional+1 (555) 01XXnumbers for send/outbound testing (POST /sandbox/provision-numbers), and seed fixture contacts and conversations (POST /sandbox/spawn-fixture-contacts) so a regression suite always starts from a known shape. All three reject any call that isn't authenticated with a test-mode key or scoped to a sandbox org.
Exercising SMS before launch
For outbound SMS the sandbox is a full-delivery-state simulator: you send to a magic number, and Orbit replays the same DLR sequence a real carrier would send for that state. The table on GET /sandbox/numbers documents the digit-to-state mapping; a typical walkthrough covers at least the delivered happy path, several undelivered failure codes, rejected (immediate carrier refuse), and the blocked suppression case, so your retry policy and your opt-out gate each see a real branch to handle. The full set of states is exercised with a series of sends that terminate on different trailing digits — no hand-forged webhook payloads required.
For inbound, the counterpart is POST /sandbox/inbound: one call injects a simulated inbound message (SMS, MMS, or WhatsApp) into your tenant inbox, exercising auto-responders, STOP-keyword handling, and inbox routing without a forged provider webhook. The route is gated so it can never touch a live tenant inbox — which is exactly the property that makes it safe to wire into a CI pipeline.
Voice testing rides the same test-key + magic-number model: the sandbox number provisioning endpoint mints fictional numbers with sms, voice, or mms capabilities, so a voice integration exercises the call-recording consent gate, answering-machine detection, and E911 registration flows against a test number rather than someone's real handset.
A launch-day pre-launch checklist
Orbit doesn't treat "ready to launch" as a matter of taste. GET /sandbox/pre-launch-checklist evaluates five items as complete-or-pending and reports the result against your live org: sandbox workspace ready, live workspace ready, a sandbox token minted, the integration exercised (at least one test-key call authenticated), and an IP allowlist configured on live keys. The checklist is a shared contract — the dashboard, the SDKs, and the docs all read the same ordered item IDs from the API, so the surface never drifts between your tooling and the marketing page.
That last item — the allowlist — is the load-bearing one. A sandbox token that worked is proof the integration is sound; the checklist exists to remind you that the production access posture (IP allowlist, key scopes, revocation plan) still has to be set before traffic flips.
Going live: the only thing left to flip
Once the checklist reports every item complete, going live is a key swap, not an integration rewrite: mint a live key (no dv_test_ prefix), update the one credential your integration reads, and leave the code exactly as the sandbox validated it. Everything else — the webhook handlers, retry policy, suppression gate, inbox routing — already ran against the states live traffic will actually produce.
The sandbox stays useful after launch day. Masked regression suites run on every release against the same magic numbers; a new channel or provider still starts in the sandbox; and when you're told "we couldn't reproduce the bug", the sandbox state-control endpoints reset the workspace to the known-broken shape and produce a reproducible case.
Frequently asked questions
Is the Orbit sandbox free to use?
Yes — test keys are free to mint, and the sandbox sibling workspace is provisioned alongside every live product org. Sandbox traffic doesn't touch real carrier capacity, so exercising it costs the same as reading the dashboard.
Can a sandbox key ever send live traffic?
No. The dv_test_ prefix is resolved as a test-mode credential at auth time, and the sandbox-only routes reject any call scoped to a live org. A live key and a sandbox key can't be substituted for one another in either direction.
What do I need to know to assert a specific delivery state?
The magic-number table — read it via GET /sandbox/numbers, or the docs page the response links to. Each trailing digit maps to one deterministic state: delivered on 0, several failure codes on other digits, blocked (suppression), and unknown (carrier never reported a final state).
How do I test inbound SMS or WhatsApp, not just sends?
POST /sandbox/inbound injects a simulated inbound message (SMS, MMS, or WhatsApp) into your tenant inbox, so auto-responders, STOP handling, and inbox routing see a real inbound shape without a forged webhook.
What does the pre-launch checklist check?
Five items: the sandbox workspace is ready, the live workspace exists, a sandbox token has been minted, the integration has actually exercised the sandbox (a test-key call was authenticated), and the live key has an IP allowlist configured. All five complete, and the API reports readyForLaunch: true.
After launch, is the sandbox still useful?
Yes — regression suites run against the magic numbers on every release, new channels or providers start in the sandbox first, and the reset endpoint rebuilds a known-broken workspace when someone reports a bug they can't reproduce.
---
Published 26 September 2026.