Skip to main content

Worked sandbox samples

The endpoint list below documents every operation’s parameters; this overlay walks a sandbox environment the way a pre-launch integration checklist actually uses it: list the sandbox numbers → read the pre-launch checklist → handle a provisioning reset. Success envelopes are { data, meta }, error envelopes { error, meta } — see How to read a worked sample. A sandbox (dv_test_sk_*) key drives the whole pipeline, and a reset always leaves your tenant with the clean fixture set the checklist expects. Every response carries meta.request_id. Quote the request id when you report a provisioned number that vanishes between calls or a checklist item that flips mid-run.

1. List sandbox numbers

GET /api/v1/sandbox/numbers returns the sandbox phone numbers provisioned for your tenant — the pool the rest of the sandbox surfaces send/receive from. Use this to verify the provision-numbers route below landed before you spawn fixture contacts.
200

2. Read the pre-launch checklist

GET /api/v1/sandbox/pre-launch-checklist returns the readiness items a launch gate evaluates — provisioned numbers, expected fixture contacts, inbound and outbound smoke-paths. Use it to decide when the tenant is a candidate for the live dv_live_sk_* cutover.
200

3. Errors

Errors follow the { error, meta } envelope. The failure every sandbox runner hits: 422 — malformed provisioning body. A reset or spawn-fixtures call with a body the sandbox pipeline cannot validate:
422