Every question, answered

Through your Zinc Wallet — a prefunded balance you top up at app.zinc.com. Each order draws the item cost, tax, shipping and the $1 fee from that balance, so there is no payment object on the request. An order that would take you below zero is rejected as insufficient_funds rather than partially placed.

Yes. Tracking numbers are automatically extracted from retailer shipping notifications and added to your order once items ship. Each tracking record includes the carrier name (UPS, FedEx, USPS, Amazon Logistics, DHL) and tracking number.

An order may have multiple tracking numbers if items ship separately. Note that tracking may not be available immediately after an order is placed — we recommend periodic polling. See our tracking docs for full details.

There’s no hard limit. We support high-throughput ordering and batched order creation. Rate limits are high and tunable based on your volume. Create as many orders as you want — large volumes will be queued and completed in the order they are submitted.

Ask the API rather than a page that goes stale: GET https://api.zinc.com/retailers returns the current list, free and with no key. It grows regularly, and with your own retailer accounts you are not limited to it at all.

Yes — test mode is a full sandbox with isolated data, its own webhook config, and rehearsal products for every failure mode, so you can exercise out-of-stock, price-exceeded and shipping-unavailable before any of them happen for real. Returns route through it too. An agent can mint its own zn_test_ key at POST /sandbox/keys with no account at all.

From the carriers directly. We poll them ourselves rather than only reading what gets reported to us, which is what gives you real checkpoints and a full delivery history instead of a status that jumps straight from shipped to delivered. We can also retrieve tracking that is only visible behind a login, which is otherwise where numbers go missing. None of it needs polling on your side: order.tracking_received and order.delivered fire as they happen.

While it is still in our queue, yes — cancel it and your wallet is refunded. Once it has been placed with the retailer, we do not drive a cancellation on their site for you, so the practical path is a return once it arrives. If the retailer cancels it themselves, order.cancelled fires with the reason and your wallet is refunded automatically.

The amount you enter is what lands in your wallet; the processing fee for the method is added on top of what you are charged. Card is 2.9% + $0.30, ACH is 0.8% capped at $5.00, and a wire is a flat $15.00. Self-serve top-ups run from $15.00 to $100,000.00, and you can wire any amount you like — the details and your memo code are in Settings. Test and production wallets are kept separate.

On your own retailer accounts, yes — ask us and we will get you set up. On ours, no: the accounts we buy from are US accounts, so orders placed on Zinc's own accounts ship within the US, Germany and Italy.

Yes, as CSV — orders, tracking and bulk-batch results all export that way, and every batch has a results file at GET /orders/bulk/{batch_id}/results.csv. Anything you can export you can also read from the API.

$1 per successful order plus the cost of the item — failed orders are not billed. Product data is priced separately, at $0.01 per call on the agent endpoints.

Either yours or ours, and it is worth being clear about the difference.

On Zinc's accounts. You do nothing but fund your wallet. We hold the retailer relationships and the payment methods, and we buy on your behalf. This is the default and the fastest way to start — there is nothing to set up.

On your own accounts. You add your retailer credentials under Managed Accounts at app.zinc.com/settings/accounts, and Zinc places orders on those accounts with your payment method. You keep whatever pricing, tax exemption or business terms you have negotiated, and the order shows up in your own order history.

Both work through the same API call; the only difference is which account the order lands on.

Much the same things that go wrong when you shop online, except typed so you can branch on them: the item is out of stock, the price moved past your max_price, the variant is not available, it will not ship to that address. Each comes back as a code rather than a stalled request, and a failed order is not billed.

About an hour. Hand your agent the quickstart or our setup prompt and it will read the spec, mint a test key and place a sandbox order without you writing much at all. The first call is one request; what is left after that is your own product logic, not retailer plumbing.

TypeScript (npm i zinc) and Python (pip install zinc), both generated from the published spec — plus installable agent skills for Claude Code, Cursor and similar tools.

Yes — test mode is a full sandbox with isolated data, its own webhook config, and rehearsal products for every failure mode, so you can exercise out-of-stock, price-exceeded and shipping-unavailable before any of them happen for real. Returns route through it too. An agent can mint its own zn_test_ key at POST /sandbox/keys with no account at all.

Set is_gift and the retailer's own gift option is used, which suppresses pricing on the packing slip. Add gift_message and we type it into the retailer's gift-message box — up to 240 characters, line breaks and emoji included. It is a hard guarantee rather than a best effort: if the gift option cannot be confirmed at checkout the order fails as gift_option_unavailable instead of shipping with a receipt in it.

From the carriers directly. We poll them ourselves rather than only reading what gets reported to us, which is what gives you real checkpoints and a full delivery history instead of a status that jumps straight from shipped to delivered. We can also retrieve tracking that is only visible behind a login, which is otherwise where numbers go missing. None of it needs polling on your side: order.tracking_received and order.delivered fire as they happen.

While it is still in our queue, yes — cancel it and your wallet is refunded. Once it has been placed with the retailer, we do not drive a cancellation on their site for you, so the practical path is a return once it arrives. If the retailer cancels it themselves, order.cancelled fires with the reason and your wallet is refunded automatically.

Every response tells you where you stand: standard RateLimit and RateLimit-Policy headers per the IETF draft, on 429 and 402 as well, alongside the legacy X-RateLimit-* ones — so an agent can pace itself without guessing. Treat a 429 as use what you have rather than a cue to retry in a loop; Retry-After says when the window resets. If you are planning something unusually heavy, talk to us first and we will size it with you.

Technically yes, and we strongly advise against it. Automating an account you do not own puts that account at risk of being closed, and it is your customer who loses it — we cannot appeal it for them and we take no responsibility for accounts that are not ours. If what you are after is negotiated pricing or tax exemption, put your own accounts on the order instead.

No. POST https://api.zinc.com/sandbox/keys mints a sandbox key with no account, no email and no human — the response includes a claim_url your operator can use later to fold the sandbox into a real account without breaking the key. Or skip keys entirely: POST /agent/orders returns an HTTP 402 carrying payment challenges, and settling one places the order.

Whichever way its wallet speaks. The 402 response carries live challenges for USDC on Solana, Base or Tempo, and fiat via Stripe, over either x402 or MPP. Every on-chain settlement is recorded by its transaction hash, and each hash pays for exactly one thing. Prefer the classic route? Fund a wallet once and spend it down with an API key.

Every order requires a max_price — a hard ceiling in cents that you set, not the agent. Zinc charges your stated max price plus the $1 fee upfront, then refunds the difference once the order completes. If the price moves past the ceiling between search and checkout, the order fails with max_price_exceeded instead of spending more.

Yes, wherever money moves. Wallet top-ups happen on a hosted page a person pays with a card, and over MCP anything that spends money waits for a person to confirm it. The scopes an agent gets (orders:write, wallet:write, products:read) are granted by you and revocable by you.

You get a typed error code, not a stalled request: out_of_stock, max_price_exceeded, invalid_variant, shipping unavailable. An agent can branch on any of them and the failed order is not billed. The sandbox carries a rehearsal product for each one, so the first time your code meets a failure is not in production.

Yes — point an assistant at https://mcp.zinc.com/mcp. It signs in as you through OAuth, with scoped access you approve on the consent screen and can revoke any time. Once connected it can search products, place orders, follow tracking and top up the wallet — with a person confirming anything that spends money.

Everything is published for machine readers: https://www.zinc.com/llms.txt indexes the documentation, https://api.zinc.com/openapi.json is the full spec, and https://api.zinc.com/sandbox/quickstart walks an agent from nothing to a delivered sandbox order in about two minutes. There is also an installable Universal Checkout skill.

Every response tells you where you stand: standard RateLimit and RateLimit-Policy headers per the IETF draft, on 429 and 402 as well, alongside the legacy X-RateLimit-* ones — so an agent can pace itself without guessing. Treat a 429 as use what you have rather than a cue to retry in a loop; Retry-After says when the window resets. If you are planning something unusually heavy, talk to us first and we will size it with you.

Yes. It is not the default — most people start on Zinc's accounts and never change — but if you have negotiated pricing, tax exemption or business terms worth keeping, add your credentials under Managed Accounts and Zinc places orders on your accounts with your payment method.

Every batch produces a results file with the outcome of each line (GET /orders/bulk/{batch_id}/results.csv), so reconciliation is something you open in a spreadsheet rather than a conversation with support.

Validate the batch first: you get the failing rows and the reason back before anything is bought, so an unavailable item or a bad address never becomes a partial spend you discover later.

On your own accounts, wherever those accounts can buy — you are not restricted to a list we maintain. On Zinc's accounts, GET https://api.zinc.com/retailers is the current set, free and unauthenticated.

Set is_gift and the retailer's own gift option is used, which suppresses pricing on the packing slip. Add gift_message and we type it into the retailer's gift-message box — up to 240 characters, line breaks and emoji included. It is a hard guarantee rather than a best effort: if the gift option cannot be confirmed at checkout the order fails as gift_option_unavailable instead of shipping with a receipt in it.

While it is still in our queue, yes — cancel it and your wallet is refunded. Once it has been placed with the retailer, we do not drive a cancellation on their site for you, so the practical path is a return once it arrives. If the retailer cancels it themselves, order.cancelled fires with the reason and your wallet is refunded automatically.

Every response tells you where you stand: standard RateLimit and RateLimit-Policy headers per the IETF draft, on 429 and 402 as well, alongside the legacy X-RateLimit-* ones — so an agent can pace itself without guessing. Treat a 429 as use what you have rather than a cue to retry in a loop; Retry-After says when the window resets. If you are planning something unusually heavy, talk to us first and we will size it with you.

Yes. It starts at a thousand orders a month — email sales@zinc.com.

Technically yes, and we strongly advise against it. Automating an account you do not own puts that account at risk of being closed, and it is your customer who loses it — we cannot appeal it for them and we take no responsibility for accounts that are not ours. If what you are after is negotiated pricing or tax exemption, put your own accounts on the order instead.

On your own retailer accounts, yes — ask us and we will get you set up. On ours, no: the accounts we buy from are US accounts, so orders placed on Zinc's own accounts ship within the US, Germany and Italy.

Yes — call offers for the product. Offers is the one that carries live price, availability and the seller behind each one, which is what you need to decide; product details describe the item rather than what it costs you today.

Whichever way its wallet speaks. The 402 response carries live challenges for USDC on Solana, Base or Tempo, and fiat via Stripe, over either x402 or MPP. Every on-chain settlement is recorded by its transaction hash, and each hash pays for exactly one thing. Prefer the classic route? Fund a wallet once and spend it down with an API key.

$1 per successful order plus the cost of the item — failed orders are not billed. Product data is priced separately, at $0.01 per call on the agent endpoints.

Yes. It starts at a thousand orders a month — email sales@zinc.com.

The amount you enter is what lands in your wallet; the processing fee for the method is added on top of what you are charged. Card is 2.9% + $0.30, ACH is 0.8% capped at $5.00, and a wire is a flat $15.00. Self-serve top-ups run from $15.00 to $100,000.00, and you can wire any amount you like — the details and your memo code are in Settings. Test and production wallets are kept separate.

It depends on the retailer, and the spread is wide: some come back in under ten seconds, others take a couple of hours when the retailer is slow to confirm. You do not have to sit on it — order.placed fires when it lands, and order.failed if it does not.

Yes, up to ten items in a single order. Past that, split it across orders — or use a bulk upload, which is built for exactly that and hands back a per-row results file.

Through the returns API. There is no way to start one from the dashboard today, so it is an API call. From there the lifecycle is webhooks: return.created, return.approved, return.denied, return.credited. The label arrives on the return itself, ready to hand to your customer.

Yes — tracking lands on the order and the events fire as they happen: order.tracking_received, order.delivered, and estimated_delivery_date on each tracking number. Customer-facing shipping emails are a separate paid feature, and they go to your end customers rather than to you.

Through our own search — GET /search across retailers, or GET /products/search?retailer=<domain> within one storefront. You do not need a third-party search tool in the loop; describe what you want and the model can go from a query to a buyable product URL with the endpoints it already has.

Yes. Add them under Managed Accounts at app.zinc.com/settings/accounts and Zinc places orders on those accounts using the payment method on file, so make sure one is set before you order.

Yes — USDC on Solana, Base or Tempo, over either x402 or MPP. Every settlement is recorded by its transaction hash, and each hash pays for exactly one thing.