
Abunda
Abunda enables flexible payment plans and lease-to-own options on millions of products, so shoppers can get what they need now and pay over time.
- $19M+
- volume processed
- 40,000+
- orders placed
Whatever your product needs bought — a user’s pick, a customer’s reward, the company’s own restock — one API buys it. No retailer deals to sign, no checkout to reverse-engineer, nothing to fix when a retailer redesigns.
Every retailer is different, everything changes constantly, and none of it was designed to be automated. Here is where everyone gets stuck.
There is no official way to place an Amazon or Walmart order from code. Nothing to authenticate against, no endpoint to call.
Checkout automation is brittle, and it fails at the worst moments. Keeping it working is our full-time job — it shouldn’t be yours.
Your order has shipped!
no-reply@retailer.com
Delivery update — action req…
tracking@carrier.io
Return window closing soon
no-reply@retailer.com
Your package was delivered
updates@carrier.io
Refund processed for item…
no-reply@retailer.com
Your order has shipped!
no-reply@retailer.com
Delivery update — action req…
tracking@carrier.io
Return window closing soon
no-reply@retailer.com
Your package was delivered
updates@carrier.io
Refund processed for item…
no-reply@retailer.com
Everything after the order is scattered: confirmation emails that differ by retailer, tracking that lives behind a login.
One API covers the whole purchase: find it, buy it, track it, and send it back if it has to go.
Beautifully designed and exhaustively thorough — every endpoint, every failure code, every edge case. And your agent can read them too.
Assistants that shop, storefronts with no inventory, rewards that ship.
Companies across payments, gifting, procurement and more put real order volume through Zinc.
Enough to tell whether this is worth a sprint, before you spend one.
Read every questionYes, 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.