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.
How you use it
An API, or a dashboard built around your use case.
The same engine underneath, delivered whichever way the work actually happens. Most teams end up using both — software reads the API, people read the dashboard, and neither is looking at a different truth.
For software that acts on the answer
Agents, repricing engines, comparison sites and catalogue pipelines. Every value carries its source channel and confidence; every match carries a method you can filter on.
For people who need to see and decide
Built around your use case rather than a fixed template — the competitive set, the alerts and the views that match how your team already works, on the same observations.
For analysts who model it themselves
The full append-only series in bulk. A view you cannot get behind is a set of decisions already made on your behalf, so the underlying observations always come with it.
Industries
Built for how each category actually prices.
Consumer Electronics Price Monitoring
Electronics is the category where price moves fastest and shoppers compare hardest.
Grocery & CPG Price Monitoring
Grocery breaks naive price comparison.
Apparel Price Monitoring
Apparel has almost no GTIN coverage, enormous variant counts, and a markdown calendar that matters more than any single price.
Marketplace Price Monitoring
On a marketplace the interesting entity is not the product, it is the seller behind the current offer.
Furniture Price Monitoring
In furniture the sticker is rarely the cost.
Beauty Price Monitoring
Beauty is the category where selective distribution meets an open marketplace.
Sporting Goods Price Monitoring
Outdoor retail runs on a seasonal clock.
Auto Parts Price Monitoring
Auto parts is a fitment problem before it is a price problem.
Solutions
Ten jobs, one substrate.
AI Shopping Agent API
An agent that returns a price has done a lookup.
Repricing Data API
Repricing quality is bounded by how fast you learn a competitor moved and how sure you are the move is real.
Brand Price Protection
Detection is the easy half of enforcement.
Build a Price Comparison Site
Comparison sites live and die on two things: whether the products are actually the same, and whether the discounts are real.
Supplier Price Benchmarking
Most procurement benchmarks are a screenshot and a memory.
Retail Arbitrage & Resale Data
Any tool can show two different prices.
Guides
What we measured, written down.
49 guides on how commerce data actually behaves at each source — access routes, what a single request returns, which identifiers are present, where the payload lies. Every figure is one we observed against a live source.
How to Track Prices Across Retailers
What price tracking really requires: where the data comes from, what each route costs, and why identity is harder than collection. A practical 2026 guide.
Amazon Price Monitoring & Price History
How Amazon pricing data works in 2026: PA-API's deprecation, what replaced it, why scraping fails at scale, and how to get price history through an API.
Price History API
How price history should be stored and read: append-only observations, time-weighted percentiles, why ties need midrank, and why history cannot be backfilled.
Ecommerce Product Data Collection
Getting product and price data at scale, measured: which sources are free, what a single request returns per source, and where the real constraints bind.
Shopify storefronts Price Tracking & Product Data
How to get Shopify storefronts pricing data: which access routes exist, what each returns, identifier coverage, and the traps that make naive comparison wrong.
MAP Monitoring & Minimum Advertised Price Enforcement
How MAP monitoring works: detecting violations across marketplaces, identifying unauthorised sellers, and building evidence that survives a lawyer reading it.