Search every seller.Know every price it has ever been.
The search, intelligence and interoperability engine for commerce. One API for what exists, who sells it, what it costs, what it has cost before, when it arrives, and whether to trust it.
Ask
curl https://api.commercecensus.com/v1/products/0885909950805/context?days=90 -H "Authorization: Bearer $CENSUS_KEY"
Know
{
"verdict": "excellent",
"current": "$198.00",
"seller": "bestbuy",
"percentile": 4.0,
"covered_days": 89,
"low": "$198.00",
"median": "$319.99",
"high": "$398.00",
"source": { "channel": "direct_api",
"confidence": 1.00 }
}Every seller, one query
Retailers, marketplaces and thousands of brand storefronts, resolved to canonical products.
Every price, ever
Append-only, time-weighted. The one thing that cannot be bought, only started.
Verdicts, not readings
Equivalence, delivery windows, trust flags and decisions an agent can defend.
Four surfaces, one truth
REST, webhooks, MCP and agent feeds over a single record shape.
Built for Fortune 500 retail, brand and channel teams — and for the agent platforms their customers now shop through. Protocol compatibility, not endorsement: these are open specifications this API implements.
What we are
Commerce has no index.
The web has one. Search solved documents thirty years ago. Commerce never got the equivalent — it stayed a few million separate catalogues, each with its own identifiers, its own vocabulary for the same attribute, its own idea of what a price includes, and no shared way to say that two listings are the same object.
That was tolerable while a person did the shopping. People are extraordinary at reconciling messy catalogues: you know a 12-pack is not a 24-pack, that last year’s model being cheaper is not a bargain, and that free shipping over $35 changes the answer.
We build that index. One canonical product, every seller that carries it, every price it has ever been, and the metadata a machine needs to reason rather than guess.
Why AI needs it
Software is doing the shopping now.
And software is bad at exactly the reconciliation people find easy. Five reasons this becomes infrastructure rather than a nice-to-have.
An agent has no memory of price
It sees $198 and has no basis to judge it. It cannot build ninety days of history inside a conversation, and the seller’s struck-through reference price is a marketing decision, not a fact. Without an owned history there is no honest answer to “is this good?”
Agents compare exhaustively, so identity has to be exact
A person samples three sellers; an agent checks forty. That multiplies the cost of a single bad match — one 12-pack compared against a 24-pack, or an XM4 against an XM5, and every downstream number is confidently wrong.
It is acting with real money
A wrong recommendation used to waste a click. Now it completes a purchase. That raises the bar on everything soft in this category: where a value came from, how confident the match is, whether the seller is real, and what the return terms actually are.
Price is rarely the deciding field
Delivery against a deadline, restocking fees, consumable cost over two years, and whether a listing is a region variant all reverse rankings that price alone would have decided. An agent optimising on sticker price is optimising the wrong number.
Every agent is rebuilding the same broken pipeline
Each one writes its own parsers, its own matching, its own storage — and each gets its own subtly different wrong answer. Interoperability is the whole point: one record shape, one identity, one provenance model, so commerce data means the same thing everywhere it lands.
What completes it
Search. Decide. Buy.
The first two are live today. The third is what turns an index into commerce, and it is the one part of this API we have not shipped.
Checkout for every commerce, for AI agents
One checkout contract across every connected seller, so an agent does not need a bespoke integration per merchant. Payment is delegated through an agentic payment protocol rather than handled here — we never hold card data.
It is also where address-level delivery becomes possible. Until an order exists there is no routing decision to resolve, which is why our delivery estimates are honest about being regional rather than promising a doorstep.
Everything else on this site is built and callable. This is the one thing that is not.
POST /v1/checkout
{ "offer_id": "off_2c81",
"quantity": 1,
"destination": { /* resolved at checkout */ },
"payment": { "delegated_token": "…" },
"on_behalf_of": "user_9f21" }
→ 202
{ "checkout_id": "chk_9a12",
"status": "pending_confirmation",
"delivery": { "date": "2026-09-10",
"granularity": "address" },
"total_minor": 19800 }What it is
Search and price history, in one place.
Most tools do one or the other. A search index tells you what exists and what it costs today; a price tracker tells you what one product used to cost. Neither answers the question anyone actually asks, which is whether the thing in front of you is worth buying right now.
Find it anywhere
One query resolves across every connected storefront. Any identifier, a product link, or plain language — the join happens here, not in your code.
Every price it has been
Append-only history per product per seller, time-weighted, going back as far as we have watched it. Low, median, high, and how long each price actually held.
Remember the shopper
Durable, namespaced memory so an agent carries preferences and constraints between sessions instead of re-interviewing the user.
Who buys it
Two very different customers.
Need a verdict, in one call
An agent has no history and cannot build one inside a conversation. It needs “excellent, 4th percentile of 89 days” rather than “$198.00” — and it needs that in a tool call with a declared cost, because nobody is approving individual calls.
Need the underlying data
Retailers, brands and marketplaces want the series, not the summary: every observation, per seller, exportable to NDJSON or Parquet, with provenance attached so an analyst can weigh it. The verdict is the agent’s job; the record is theirs.
Why this one
A number is a claim. We tell you whose.
Every vendor in this category returns a figure. None will say where it came from, and none publish an accuracy rate. So observations here are immutable, and each carries its origin and a weight — you can filter on it, alert on it, and decline to act on it.
Industries
Built for how each category actually prices.
Commerce intelligence for consumer electronics
Electronics is the category where price moves fastest and shoppers compare hardest.
Commerce intelligence for grocery and CPG
Grocery breaks naive price comparison.
Commerce intelligence for fashion and apparel
Apparel has almost no GTIN coverage, enormous variant counts, and a markdown calendar that matters more than any single price.
Commerce intelligence for marketplaces
On a marketplace the interesting entity is not the product, it is the seller behind the current offer.
Commerce intelligence for home and furniture
In furniture the sticker is rarely the cost.
Commerce intelligence for beauty and personal care
Beauty is the category where selective distribution meets an open marketplace.
Commerce intelligence for sporting goods and outdoor
Outdoor retail runs on a seasonal clock.
Commerce intelligence for auto parts
Auto parts is a fitment problem before it is a price problem.
Solutions
Ten jobs, one substrate.
The commerce API for AI shopping agents
An agent that returns a price has done a lookup.
Real-time competitive data for repricing engines
Repricing quality is bounded by how fast you learn a competitor moved and how sure you are the move is real.
Policy enforcement with evidence attached
Detection is the easy half of enforcement.
Power a comparison site without running a collection team
Comparison sites live and die on two things: whether the products are actually the same, and whether the discounts are real.
Negotiate against a distribution, not an anecdote
Most procurement benchmarks are a screenshot and a memory.
Spread, landed, and whether it holds
Any tool can show two different prices.