Let your AI agents buy from 500M+ products online
Permissionless buying across the internet — beyond what a browser session can do. Your agent finds the product, pays its own way and follows the parcel to the door, whether that is one order or ten thousand.
Beyond what a browser can do
Driving a checkout page is the demo. Buying, tracking, returning and paying — as one system, at any volume — is the product.
Reach
The whole internet is the catalog
Hundreds of millions of products across the stores people actually buy from, searchable and buyable through one surface.
After checkout
A full system around every order
A browser session ends at the confirmation page. Zinc keeps going — tracking, delivery, returns — with every event pushed as it happens.
Payment
It pays its own way
The price comes back before anything is committed, and the agent settles it in the same exchange — one order or ten thousand.
Teach your agent to buy
Install the checkout skill in the agent you already run — or let it sign itself up and start in the sandbox.
# Add the Universal Checkout skillmkdir -p ~/.claude/skills/universal-checkoutcurl -sL https://www.zinc.com/skills/universal-checkout/SKILL.md \ -o ~/.claude/skills/universal-checkout/SKILL.md # Then just ask"Order a 12-pack of AA batteries to the office"No account needed to start.
Put an agent on it
Twelve working agents. Open any card for the full prompt, ready to run.
Your agent’s first order is our twenty-millionth
An agent platform is a claim about what happens at order ten thousand, not order one.
Orders placed
0M+
Goods delivered
$0M+
Years in production
0
API requests a year
0M+
Pay by human. Pay by robot.
Some spend needs a person’s sign-off. Some should never wait for one. Zinc settles both.
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.





























