​

The developer loop: sandbox → playground → first live send

This guide walks the full first-week loop in one pass: provision a sandbox key, see what the Sandbox page gives you, drive a real request through the API playground, lift the generated curl and SDK code out of it, and graduate the same call to live when you are ready. Two other guides cover each half in depth: Sandbox and test mode and API playground. This one is the connective path — the order to do things in, and what to expect as you move between surfaces.

​

1. The sandbox primitives

• The test key prefix. Sandbox keys start with dv_test_sk_. The prefix decides the mode: a test key is always sandboxed on every request, and no request header can override it.
• Cost: $0. Sandbox sends are simulated end to end — no provider is called and no balance moves, so you can mint and exercise a key before any KYC or funding step.
• A response marker. Every sandboxed response carries meta.test_mode: true. Assert on that marker in your tests rather than on which key you meant to use.
• Deterministic outcomes. The trailing digit of the recipient picks the delivery result: +15005550002 delivers, +15005550003 does not. The full table lives at Sandbox magic numbers.

​

2. Open Developer → Sandbox

The Sandbox page is the orientation surface for a first session. It gathers everything you need before you send anything: Do two things here before moving on: mint a dv_test_sk_ key (or copy one you created under Settings → API keys), and note the sandbox sender +15550100 you will send from.

​

3. Take the same key into Developer → API playground

The playground is the dashboard’s interactive request builder. It picks the first active key that matches the current mode, so with your new test key in place, flip the builder’s toggle to Sandbox and the status line under the form names your dv_test_sk_ key. With no matching key, Send stays disabled. The page lays out in three panes:

• Endpoints (left) — a curated catalog of the most-used public endpoints, grouped under Messages, Voice, Contacts, Campaigns, and more.
• Request builder (centre) — a form rendered from each endpoint’s schema, with the global Sandbox/Live toggle in its header.
• Code + result (right) — the code preview (cURL, Node, Python, Go, Ruby, PHP), the response card, and Recent requests.

Recent requests is your scratchpad: the last 50 runs (method, path, mode, status, duration) stored in this browser’s localStorage only. It never reaches a server, and the Clear button empties it. The durable, workspace-wide record is the Request Logs console.

​

4. The worked full loop

1. Provision. Mint a dv_test_sk_ key from the Sandbox page’s Test API keys card, or under Settings → API keys.
2. Open the playground and flip the toggle to Sandbox. The status line should name your test key.
3. Pick the endpoint. Under Messages, choose Send SMS (POST /messages).
4. Fill the form. channel — sms; to — +15005550002; from — +15550100; body — Hi from Orbit!
5. Hit Send. The response card shows a success badge and a body like:
   {
     "data": { "id": "msg_…", "status": "test_sent" },
     "meta": { "request_id": "req_…", "test_mode": true }
   }
   
   test_sent is the terminal sandbox state: the message was accepted and simulated, not dispatched.
6. Lift it as curl. The code panel renders the same request:
   curl -X POST "https://api.orbit.devotel.io/api/v1/messages" \
     -H "X-API-Key: dv_test_sk_…" \
     -H "Content-Type: application/json" \
     -d '{
       "channel": "sms",
       "to": "+15005550002",
       "from": "+15550100",
       "body": "Hi from Orbit!"
     }'
   
   The panel masks your key to prefix plus last four — substitute the full key before you run it in a terminal.
7. Lift it as SDK code. Switch the panel to Node, Python, Go, Ruby, or PHP: the same request through the official SDK for that language, reading the key from ORBIT_SANDBOX_KEY. Paste it into your codebase and your integration now makes the exact call you just verified by eye.
8. Exercise a failure path. Send again with to set to +15005550003 and inspect the failed shape in the response card — that is the response your retry and alerting logic must parse.

Both runs now sit side by side in Recent requests for comparison.

​

5. What the playground does not do

• No live carrier dispatch. In sandbox mode every send terminates at test_sent or the simulated failure you chose. No real phone rings.
• No wallet-side effect. Nothing deducts from your balance, and sandbox traffic never appears on an invoice.
• Sender validation still applies. The sandbox simulates delivery, not permission: from must be a sender in your tenant, which is why the worked example uses the sandbox sender +15550100.
• History is browser-local. The request list lives in that browser only. Clearing browser data starts fresh; the durable record is Request Logs.

​

6. The same call, live

When the loop above passes:

1. Complete KYC and fund your balance — both are required before live sending.
2. Mint a live key (dv_live_sk_) under Settings → API keys. A test key is never promoted; the prefix is the mode, so going live always means a new live key.
3. Flip the playground toggle to Live, or swap ORBIT_SANDBOX_KEY for ORBIT_API_KEY in your code, and send the same body. The request is real now: it dispatches and it bills.
4. Walk the production go-live checklist for numbers, webhooks, and compliance. The Sandbox page’s pre-launch checklist card shows what remains.

Your request bodies do not change between modes — that is the point of the loop.

​

See also

• Quickstart — first sandbox key and first send in five minutes
• API playground — the full playground reference, including its failure-mode table
• Sandbox and test mode — the key, header, and session-auth routing matrix
• Sandbox magic numbers — every trailing-digit scenario