Skip to main content
Going live is two separate things, and it helps to keep them apart:
  1. Claiming — a human adopts the sandbox into their Zinc account. The agent’s key survives.
  2. Switching to live — the account owner mints a zn_live_ key and funds a wallet.
You can do the first without the second. Claiming preserves work; it doesn’t spend money or enable real orders.

​
Claiming

The mint response included a claim_url. Give it to the human you work for:
“I’ve built and tested the ordering flow against a Zinc sandbox. To adopt it into your account, sign in here: https://app.zinc.com/claim/...”
When they sign in there, the sandbox folds into their Zinc account:
Not revoking the key is the entire point. An agent that’s been running against a sandbox for a week doesn’t need redeploying, reconfiguring, or a secret rotation to keep working.
Claiming is always a merge into the signed-in account — signing in creates the account if it didn’t exist, so there’s always something to merge into.
The claim token is single-use and lives only in that URL. Only its hash is stored, so the URL can’t be reproduced — if it’s lost, mint a new sandbox and hand over the new one.

​
Knowing when it happened

An agent that hands off a URL can’t see what the human did next. Poll for it:
Every response carries a plain-language hint, so an agent can act on the answer without special-casing each shape.

​
Switching to live

A claimed key is still a sandbox key. It reaches sandbox data only, claimed or not. Claiming moves ownership; it does not grant the ability to spend.
To place real orders, the account owner:
1

Funds a wallet

Deposit a balance in the dashboard. Each order draws its cost plus the account’s order fee. See Wallet for the fee schedule, or Stripe Connect and MPP for the other payment rails.
2

Mints a live key

A zn_live_ key, from the same dashboard.
3

Hands it to the agent

The API surface is identical. Change the key, keep the code.

​
What changes when you switch

The request and response shapes don’t change. The environment around them does:
Because the sandbox skips those validations, your first live order can fail in ways no test did — a rejected address, an unreachable URL, a real out-of-stock. Handle order_failed and the synchronous rejections before you switch, not after.

​
Before your first live order

  • Handle both failure timings. Some errors come back from POST /orders; others arrive minutes later as order_failed. See Error Handling.
  • Set max_price to cover the real total. Item plus tax plus shipping — a ceiling that only covers the item price trips max_price_exceeded on live orders that would have passed in the sandbox.
  • Re-register webhooks. Test-mode webhook config is separate from live; a live key won’t inherit it.
  • Send an idempotency key. On live orders, a retry without one is a second order. See Idempotency.
  • Start small. One cheap real order end to end before you turn on volume.

​
Reference

Claim a Sandbox

POST /sandbox/claim — request and response by field.

Get Sandbox Status

GET /sandbox/status — every response shape.