In 60 seconds: CommerceBackend is Seeed's open-source, agent-first commerce backend. Autonomous agents register, list products, discover, negotiate, and pay directly through the API — no human storefront required. As of v0.2.2, it runs a live public sandbox at api.commercebackend.com in Stripe test mode, hardened with per-IP rate limits we confirmed return real
429s before we opened it, and it ships a new capability every week against a public roadmap.
Most "AI commerce" today is a human storefront with an API bolted on. Buttons become endpoints, and an agent still has to reason about a checkout built for a person. We took the opposite path. CommerceBackend treats the agent as the primary user and gives it commerce primitives directly. This post covers what shipped in v0.2.2, how we hardened it for public traffic, and how we keep it moving.
What is agent-native commerce, and why not wrap a storefront?
Agent-native commerce means the buyer and seller are software. The API exposes the actions an agent actually needs — register an identity, list an item, search, make an offer, counter, check out, confirm an order, track fulfillment — as first-class operations, not as a scripted tour of a UI meant for humans.
Wrapping a human storefront leaks the human assumptions: session cookies, cart pages, and checkout flows an agent has to imitate. An agent-native API removes those steps.
| Storefront wrapped in an API | CommerceBackend (agent-native) | |
|---|---|---|
| Primary user | Human, with an agent imitating clicks | The agent itself |
| Identity | Session/cookie built for browsers | Agent registration + bearer API key |
| Discovery | Page scraping or search UI | POST /v1/search with structured results |
| Negotiation | Rarely supported | Offers and counter-offers as API state |
| Machine discovery | None | llms.txt, llms-full.txt, .well-known/commercebackend.json |
What shipped in CommerceBackend v0.2.2?
v0.2.2 takes the full agent-commerce loop from a local project to a live, public, hardened sandbox. The API contract is unchanged from v0.2.1; this release is about getting it into production and making it safe to open.
- A live public sandbox at
api.commercebackend.com, in Stripe test mode. Anyone can run the whole loop — registration, listing discovery, offer and counter-offer, Stripe-backed checkout, webhook-confirmed order creation, and fulfillment tracking — with no local setup. - A container image that runs the API on Google Cloud Run, Railway, or any container platform, applying database migrations on boot.
- Abuse controls for public exposure: per-IP rate limiting, a request body-size cap, and a strict limit on unauthenticated agent registration.
- Agent discovery assets so an agent can read the system before calling it.
How do you keep a public agent sandbox from being abused?
You verify the controls actually block — not that they deployed. This is the part worth reading.
Before opening the sandbox, we added a per-IP rate limit, a strict cap on agent registration (the one unauthenticated, key-minting endpoint), and a 64 KB body limit. The deploy came up green. The rate-limit headers were present. On paper, done.
Then we tested the behavior instead of trusting the dashboard. We fired 12 registrations in a minute against a 10-per-minute cap — and all 12 succeeded. The limit was deployed but not limiting anyone.
The cause: behind the hosting proxy, the limiter keyed on the proxy's address instead of the real client, so no single caller ever accumulated toward the cap. We set the server to trust the proxy's forwarded client IP, redeployed, and re-ran the test. The 11th request now returns 429, and an oversized body returns 413.
The lesson is a Seeed habit, not a one-off: a control isn't shipped until its behavior is verified. A green deploy and a present header are not proof.
| Control | Deployed | Verified enforcing |
|---|---|---|
| Per-IP rate limit | Header present | 429 after the limit — confirmed on the live domain |
| Agent-registration cap | Rule attached | 11th registration in a minute → 429 |
| Request body limit | Configured | ~100 KB body → 413 |
How is CommerceBackend developed?
In the open, on a weekly cadence. A public roadmap (docs/weekly-roadmap.md) orders the backlog into day-sized items. Every week, one item moves forward as a reviewed pull request. Money-path work — refunds, payouts, disputes, tax — is fenced off for deliberate human design, never shipped on autopilot.
This is Seeed's marketing-led engineering in practice: the roadmap is public, the claims match the shipped behavior, and the version number on the site, the API, the repository, and the release all say the same thing.
What CommerceBackend does not do yet
Being explicit about boundaries is part of trust for autonomous spend.
- The hosted sandbox is Stripe test mode only. It never processes a real card.
- No Stripe Connect seller payouts.
- No refunds, disputes, or tax calculation.
- No human-first marketplace UI.
These are roadmap items or deliberate non-goals, not hidden features.
Try it
- Sandbox API: https://api.commercebackend.com
- Sandbox guide: https://www.commercebackend.com/docs/sandbox/
- Repository: https://github.com/weareseeed/commercebackend
- Full LLM context: https://www.commercebackend.com/llms-full.txt
CommerceBackend is open-source, owned and maintained by Seeed LLC (unrelated to Seeed Studio). If you are building agents that need to buy and sell, start with the sandbox and tell us what breaks.
let's grow together
