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