A price comparison API answers one question completely: for this exact product, what is every seller charging? This collector opens a Google Shopping product page and delivers the per-seller offer list — seller, price, currency, the total including shipping where Google shows it, and the link to buy — plus the product's rating, review count and Google's typical price range.
It takes either a product_id from a Google Shopping run, or a plain query that it resolves to the first shopping result for you. The second form is the convenient one for ad-hoc lookups; the first is the one you use in a pipeline, because an id is stable and a query is not.
$0.002 per delivered offer, up to 50 offers per run. Nothing delivered means nothing charged.
Give it an id and it goes straight to that product's offer page. Give it a query and it resolves the query to a shopping result first, then does the same thing — one extra hop, no extra call on your side.
What comes back is the offer table as Google assembled it, one row per seller, ordered as shown. The field that earns its keep is total_price: the headline price and the delivered cost are frequently different sellers' idea of cheap, and a comparison built on price_value alone ranks the seller with the most aggressive shipping charge first. Where Google publishes a total, this collector keeps it separate rather than merging it.
Alongside the offers you get product_rating, product_reviews and typical_prices — Google's own sense of the normal range for this product, which is a useful sanity check against a single anomalous offer.
Either product_id or query — neither is individually required, but you need one of them. Use the id in anything scheduled: it is stable across runs, whereas a query can resolve to a different product when the catalogue shifts. country and lang set the market and the exit; max_results caps how many offers are delivered and therefore what you pay.
One row per seller offer. price_value is the numeric item price and total_price is the delivered cost where Google exposes it — compare on the second if you want a comparison that reflects what a customer pays. link is the seller's own destination, so the row is directly actionable. The product-level fields (product_title, product_rating, product_reviews, typical_prices) repeat on every row, which keeps the output a flat table you can load straight into a warehouse without a join.
$0.002 per delivered offer ($2 per 1,000). Nothing delivered means nothing charged, and the $2 monthly free credit covers roughly 1,000 offers here. Volume tiers take up to 30% off.
$0.002 per delivered offer, $2 per 1,000 — twice the shopping-search rate, because an offer page is a second fetch and a heavier parse. Watching 100 products daily at roughly 12 offers each is around 1,200 offers a day, about $2.40 at list price, less on a volume tier.
That price difference is the reason to run this narrow. Use the Shopping collector to decide which products deserve a full seller list; use this one only on those. Products that return no offers cost nothing.
The commercial price-comparison APIs that dominate this search are mostly affiliate networks: they return offers from merchants who are in the network, with tracking links attached, because the business model is commission rather than data. That is genuinely useful if you are monetising outbound clicks. It is the wrong dataset for repricing or market research, because coverage is a function of who signed a contract, not of who sells the product.
Google has no public API for reading Shopping offers at all — the Content and Merchant APIs manage your own feed. So the realistic choice for full-market coverage is reading the public offer page, which is what this does. The trade is that you get every seller Google indexes and no affiliate commission, rather than a partial list with one attached.
Teams usually start by scraping five retailers directly and discover the problem is not the scraping, it is the matching:
product_id.One clustered offer page replaces N retailer scrapers and the matching logic between them.
Take the minimum and median total_price per product per day as the input to your own pricing rules — delivered cost, not headline price.
Every row already carries seller, price, total and a destination link, which is the whole payload a comparison listing needs.
Brands see who is actually selling their product and at what price. Sellers appearing outside your authorised list show up immediately.
typical_prices gives Google's own normal range, so an outlier offer can be flagged rather than acted on.
Up to 50 offers per run, which comfortably covers the seller list for almost any consumer product. Products with no offers return empty and are not billed. Throughput follows your plan's rate limit — 60 requests/minute on pay-as-you-go, up to 1,200 on the top tier — so a nightly sweep over a few thousand products is a scheduling question, not a capacity one.
Legally: prices and merchant names are public commercial data, and collecting public data is generally lawful in most jurisdictions, but Google's terms restrict automated access and the position differs by country. This is not legal advice.
The free options are almost all affiliate feeds, where coverage is limited to merchants in the network and links carry tracking. Here there is a free allowance rather than a free tier: $2 of usage a month with no card, about 1,000 delivered offers at $0.002 each.
$0.002 per delivered offer — $2 per 1,000 — with no subscription. It is twice the Shopping search rate because an offer page is a second fetch and a heavier parse. Volume tiers take up to 30% off, and products that return no offers are not billed.
Either works. A query is resolved to its first shopping result automatically, which is convenient for ad-hoc lookups. For anything scheduled use product_id: ids are stable between runs, while a query can silently resolve to a different product as the catalogue shifts.
Where Google publishes a delivered total, it comes back in total_price alongside the item price in price_value. Compare on the total if you want a ranking that reflects what a customer actually pays — headline-price comparisons systematically favour sellers with high shipping charges.
Up to 50 offers, which covers the full seller list for effectively any consumer product. You pay only for offers actually delivered.
The Shopping collector answers 'what listings does this query return', one row per listing, at $0.001. This one answers 'who sells this exact product and for how much', one row per seller offer, at $0.002. The product_id from the first is the input to the second.
Yes — pass a different country and the run uses an exit and locale for that market, returning that country's sellers and currency. Keep the currency field when comparing across markets rather than assuming one.
Skip the marketing. QuantumProxies.io publishes a machine-readable site map, Markdown for every page, a free MCP server, and APIs billed from the same balance as your proxies.
Connect in one command: npx -y quantumproxies-mcp