> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# The developer loop: sandbox key, playground, first live send

> Mint a dv_test_sk_ key, orient on the Sandbox page, drive your first request through the API playground, then graduate the same call to a live key.

# 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](/guides/sandbox-test-mode) and [API playground](/guides/developer-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](/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:

| Card | What it gives you |
| - | - |
| Mode status | The current session mode: test or live, at a glance |
| Test API keys | Mint and reveal `dv_test_sk_` keys |
| Virtual phone | A sandbox number that receives simulated inbound messages |
| Sandbox webhook | The URL simulated receipts and inbound events are posted to |
| Magic numbers | The trailing-digit-to-outcome table |
| Pre-launch checklist | The go-live gate, showing which live prerequisites are still open |

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](/guides/api-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:

   ```json theme={null}
   {
     "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:

   ```bash theme={null}
   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](/guides/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](/quickstart) — first sandbox key and first send in five minutes
* [API playground](/guides/developer-api-playground) — the full playground reference, including its failure-mode table
* [Sandbox and test mode](/guides/sandbox-test-mode) — the key, header, and session-auth routing matrix
* [Sandbox magic numbers](/sandbox/magic-numbers) — every trailing-digit scenario


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.