Skip to main content
No account needed. Four steps, and the order delivers about five seconds after you place it.
Agents: install the universal-checkout skill — npx skills add zincio/skills --skill universal-checkout — and follow its Getting started section. This page is the human-readable version of the same flow.
The same walkthrough is served as plain markdown at GET /sandbox/quickstart, written to be executed rather than read.
1

Mint a sandbox key

No authentication. An empty body works; both fields are optional:
  • name becomes the key’s label, so a human approving it later can tell what it was for.
  • email is who should be told about claiming this sandbox. Never required, never used for anything else.
The response is self-guiding:
api_key and key hold the same value — api_key is the name to use, and it’s the same field name on every key-issuing response, including the live key you get later.
Save the claim_url. It’s returned once — only its hash is stored, so it can’t be regenerated. Losing it doesn’t strand you (see Going Live), but you’d need a new sandbox to get another.
2

Place a sandbox order

Send the key as a Bearer token. Test keys route to the sandbox automatically — no extra headers, no mode flag:
That body is exactly what the mint response hands back as example_order — it can be sent unchanged.
max_price is in cents and is required on every order. It’s the ceiling you authorize for the total, including tax and shipping. phone_number is required too, and comes back normalized to E.164 (+14155552671). Leave idempotency_key out unless you’re generating a fresh UUID for it; one is generated for you when omitted.
3

Watch it happen

Sandbox orders run the real lifecycle on a fast, fixed clock measured from when the order was created:Nothing has to be running for an order to progress — no worker, no queue. Every poll returns the state the clock says it should be in.
Shipment progress lives on tracking_numbers[] and items[], not on status. The order’s own status is one of pending, in_progress, order_placed, order_failed, cancelled, cancelled_by_retailer.
Prefer not to poll? Register a webhook URL — test mode has its own webhook config, separate from live:
4

Rehearse the failure modes

Swap the product slug to reproduce each error shape. This is the part worth spending time on — a happy-path integration meets its first real failure in production.Some fail at creation, some fail after acceptance:All slugs live under https://zinc.com/shop/products/. Any other product URL — including a real Amazon one — simply succeeds in the sandbox. See Sandbox & Testing for the error payloads each one produces.
test-insufficient-funds is worth running before you go live: it returns the same insufficient_funds shape a real underfunded order does, including the fund_with rails. See Going Live.

​
Practical notes

  • Persist the key. It’s good for 7 days of inactivity and any use resets the clock. An agent that stores its key needs the mint endpoint roughly once.
  • Don’t loop on 429. The mint endpoint allows only a few keys per IP per day. A 429 means reuse the key you already have, not retry — wait out Retry-After if you genuinely need a new one.
  • 503 is retryable. The mint path fails closed when the sandbox or its rate limiter is unavailable, rather than running uncapped. Back off and try again.
  • Sandbox validations are looser than live. Balance checks, URL reachability, and address verification are all bypassed. See Skipped Validations before your first real order.

​
Next step

Going Live

Get a human’s approval, collect a live key with a starter credit, and place a real order.