Limits and pricing
Free for developers right now. When it isn't, a flat fee per completed order and nothing else.
Limits and pricing
Free for developers, right now
No card, no subscription, no trial clock, no billing to set up. Build.
There is no metering behind this page yet, which is the honest version of "free": we are not quietly counting anything to charge you for later. When that changes it will change here first, with notice, and it will not be retroactive.
Hackathon participants keep it free for six months afterwards. That was promised on the Pioneers site and it stands.
What it will cost, when it costs anything
$0.05 per completed order. Nothing else.
| Monthly subscription | none, ever |
| Order that completed | $0.05 |
| Product search and lookup | free |
| Preview, and any order refused before the card | free |
| An order that failed | free |
| Merchant or processor costs | passed through, no markup |
Three of those lines are decisions rather than omissions, and they are worth a sentence each.
No subscription. A platform fee is a qualification filter dressed as a price. It decides who is allowed to try before they know whether the thing works. You should be able to start at 3am on a personal card without asking anyone's approval, and the first order should cost five cents rather than a hundred dollars.
Search is free. Charging to look at a product taxes the exact thing we want you doing, which is exploring what the merchant network can actually get you. The catalogue is not the product; completing the checkout is.
You pay when a parcel is on its way, and never otherwise. Not for a preview, not for a failure, and specifically not for an order we refused before touching the card. That last one matters more than it reads: this API deliberately refuses orders — when a spending limit is breached, when a destination cannot be verified, when the price moved. A system that charged for refusals would have a quiet incentive to refuse. So it doesn't.
Never a percentage of the sale. What you charge your own customer is your business, and the work of completing a checkout does not get harder because the basket was bigger.
Rate limits
Your checkout quota is keyed to your API key, not to your IP address. That matters at an event: teams behind one office network or one venue's Wi-Fi do not share it.
| What | Limit |
|---|---|
| Reads — merchants, products, orders, evidence | 120 / minute |
Quotes — preview_order, POST /shopify/quote | 30 / minute |
Orders and discovery — place_order, discover_merchant | 10 / minute, and 200 / day |
The daily order cap is the one that bites first. A per-minute limit does nothing against a slow leak, and 200 orders a day is far more than a demo needs.
The rest of the API — everything outside /api/autofill — sits behind a separate abuse control of 100 requests per 15 minutes per IP address. The checkout routes are deliberately exempt from it, so a shared network cannot throttle your key.
Responses carry the standard RateLimit-* headers. Read those rather than counting your own requests; they are the authority.
Staying well inside them
Generous for anything a real product does, tight for a few habits worth breaking early.
Do not poll faster than the thing you are polling. An order takes sixty to seventy seconds. Every three seconds is plenty; every 300ms is twenty times the cost for the same answer.
Do not re-preview to refresh a token. A preview is free and idempotent, but it is a live call to the merchant's storefront. Cache it for the five minutes the token lives.
Never retry place_order for the same order. Not for rate-limit reasons — for double-charge reasons. If a place call times out, poll the status with the order_id it gave you.
Read retryable before retrying anything. A retry loop that ignores it will eventually retry an order where money may already have moved. That field exists to stop exactly that, and it is the one thing a retry loop must branch on.