Price comparison API

The price comparison API takes one product — by Google product id, or by name — and returns every seller offer behind it: merchant, price, total including shipping when shown, offer link, plus the product’s rating and Google’s typical price range. $0.002 per delivered offer, nothing when a run comes back empty.

Get my free API key See the request

$0.002 per delivered offer · $2 free every month · Failed runs never billed

POST /v1/scraper/collectors/product_offers/run

$ curl $QD/product_offers/run \
    -H "Authorization: Bearer $QD_API_KEY" \
    -d '{ "query": "Sony WH-1000XM5", "country": "us",
          "max_results": 20 }'
{ "status": "done", "count": 14,
  "results": [
    { "seller": "Crutchfield", "price": "$328.00",
      "price_value": 328, "currency": "USD",
      "total_price": "$328.00",
      "typical_prices": "$298 – $399",
      "product_title": "Sony WH-1000XM5" } ],
  "cost": 0.028 }
# 14 offers × $0.002 · you are billed on 14, not on 20

$0.002 / offer1,000 offers on the free $2 every month

Id or product namea query resolves to the first shopping result

Up to 50 offersper run — the whole seller list for one product

Totals with shippingwhen Google shows them, plus the typical range

What a price comparison API does

A price comparison API answers one question — "who sells this, and for how much right now" — as rows instead of a page. This collector opens the Google Shopping product page behind a product id and returns the per-seller offer list, with the price each merchant shows and the total once shipping is included.

That distinction matters: a listing price and a checkout total are different numbers, and comparisons built on the first are wrong often enough to matter. Where Google exposes a total, it is on the row as total_price; where it publishes a typical price range for the product, that is on the row too, so an outlier is visible without a history table.

The usual pairing is two collectors: Google Shopping to discover products and their ids for a query, then this one per product. If you would rather not run the loop yourself on a schedule, competitor price monitoring is the managed version of the same data.

What comes back for every offer

Twelve published fields, versioned. Prices arrive as shown and as numbers; the product context is repeated on every row so a single offer is self-contained.

Field	Type	What it holds
`seller`	string	Merchant offering the product.
`price` · `price_value`	string · number	Offer price as shown and parsed.
`currency`	string	Currency of the offer.
`total_price`	string	Total including shipping or tax, when Google shows it.
`link`	string	Link to that seller’s offer.
`typical_prices`	string	Google’s typical price range for the product.
`product_title`	string	Product title, echoed on each offer.
`product_rating` · `product_reviews`	number · integer	Rating and review count of the product.
`product_id` · `rank`	string · integer	Google product id and offer position.

Inputs: an id, or just the name

Give product_id when you already have it from the Shopping collector; otherwise a query is resolved to the first shopping result.

Input	Type	Required	What it does
`product_id`	string	preferred	Google Shopping product id, as returned by the Google Shopping collector.
`query`	string	alt	Product name — resolved to the first shopping result for the market.
`country`	string	no	ISO code: sellers, currency and shipping differ per market.
`lang`	string	no	Interface language.
`max_results`	integer	no	1–50, default 20. Most products have fewer offers than the cap — you pay for the ones delivered.

Pricing

What per-offer price data costs

Each delivered offer is $0.002. A daily check on 100 products, with a dozen sellers each, is roughly 1,200 offers — about $2.40 a day at list price, less on a volume tier, and nothing on the days a product page comes back empty.

$0.002per delivered offer$2 per 1,000 delivered offers

1,000 offerson the free allowance$2 every month, no card

Zero rowszero chargeblocks, captchas and retries are on us

−30%on volume tiersthe catalog returns your key's price

Pay as you go

$0/mo

$2 free credit / month
60 requests / min
List unit prices

Starter

$19/mo

$15 free credit / month
300 requests / min
10% off unit prices

Growth

$79/mo

$50 free credit / month
600 requests / min
20% off unit prices

Scale

$299/mo

$250 free credit / month
1,200 requests / min
30% off unit prices

Same wallet, same key and same $2 monthly allowance as every other Data API. Prices are launch pricing read live from the billing config — GET /v1/scraper/collectors returns the price your key actually pays.

Integration

One POST, typed rows

Base URL https://api.quanticdata.io/v1, Bearer auth, the same key as every other Data API. Endpoint: POST /v1/scraper/collectors/product_offers/run.

# every seller offer for one product, by name
curl https://api.quanticdata.io/v1/scraper/collectors/product_offers/run \
  -H "Authorization: Bearer $QD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "query": "Sony WH-1000XM5", "country": "us",
        "max_results": 20 }'

import requests

BASE = "https://api.quanticdata.io/v1/scraper/collectors"
H = {"Authorization": f"Bearer {KEY}"}

r = requests.post(f"{BASE}/product_offers/run", headers=H,
    json={"product_id": "1234567890123456789",
          "country": "us", "max_results": 30})

offers = r.json()["data"]["results"]
offers.sort(key=lambda o: o["price_value"] or 1e9)
for o in offers[:5]:
    print(o["seller"], o["price"], "total:", o["total_price"])

const BASE = "https://api.quanticdata.io/v1/scraper/collectors";
const h = { Authorization: `Bearer ${process.env.QD_API_KEY}`,
            "Content-Type": "application/json" };

const res = await fetch(`${BASE}/product_offers/run`, {
  method: "POST", headers: h,
  body: JSON.stringify({ query: "iPhone 16 Pro 256GB",
                         country: "it", lang: "it", max_results: 30 })
});
const { data } = await res.json();
const best = data.results.reduce((a, b) =>
  (a.price_value ?? 1e9) < (b.price_value ?? 1e9) ? a : b);
console.log(best.seller, best.price, best.typical_prices);

claude mcp add quantumproxies \
  -e QUANTUMPROXIES_API_KEY=qd_live_your_key_here \
  -- npx -y quantumproxies-mcp

# then, from the agent:
run_collector  slug="product_offers"
               input={ "query": "Sony WH-1000XM5",
                       "country": "us", "max_results": 20 }

What people run it for

The offer list is the layer most price tools skip — it is where repricing decisions actually live.

Repricing

Know where you sit in the seller list for each SKU, on price and on total with shipping, before changing a number that costs you margin.

MAP and reseller checks

Unauthorised sellers and below-policy prices show up in the offer list first. The seller name and the offer link are on the row, so a violation is actionable, not anecdotal.

Comparison sites and bots

Build a "cheapest right now" widget or a Telegram bot on a per-call cost of fractions of a cent, without maintaining a scraper per retailer.

Deal validation

typical_prices is Google’s own range for that product, so a "discount" can be checked against the market instead of against a struck-through price.

Collector vs marketplace APIs vs price trackers

Three ways to answer "who sells this and for how much", and what each leaves out.

	Marketplace APIs	Price-tracker tools	This collector
Scope	one marketplace per integration	the SKUs the tool covers	every seller Google lists for the product
Access	seller account, approvals	a subscription per seat	an API key
Shipping totals	varies	rarely exposed	`total_price` when shown
Automation	yours to build	inside their UI	one POST, typed rows, CSV export
Billing	account-based limits	monthly plan	$0.002 per delivered offer

Affiliate coverage versus full coverage

Most commercial price-comparison APIs are affiliate networks: they return offers from merchants inside the network, with tracking links attached, because the business model is commission. That is genuinely useful if you monetise outbound clicks; it is the wrong dataset for repricing, because coverage is a function of who signed a contract rather than of who sells the product.

Google publishes no API for reading Shopping offers, so full-market coverage means reading the public offer page. The trade is explicit: every seller Google indexes, and no affiliate commission.

Limits, totals and the legal bit

Up to 50 offers per run — comfortably the whole seller list for any consumer product. Products with no offers return empty and unbilled. It is priced above the Shopping search collector because an offer page is a second fetch and a heavier parse, which is why the efficient pattern is to decide which products deserve a full seller list before spending on one. Throughput is your plan's rate limit rather than anything about the collector: 60 requests/minute on pay-as-you-go, up to 1,200 on the top tier.

Compare on total_price rather than price_value where Google publishes it. A headline-price ranking systematically favours whichever seller loads the most cost into shipping, which is the opposite of what a comparison is for.

Collecting publicly visible data is generally lawful in most jurisdictions, and courts have repeatedly declined to treat reading a public page as unauthorised access. Google's terms restrict automated access; prices and merchant names are commercial data. None of this is legal advice — get some for your actual use case.

FAQ

The practical questions about per-seller price data — coverage, freshness and cost.

Something else? Ask us →

What is a price comparison API?

It is an endpoint that returns every seller offer for one product as structured rows, instead of a comparison page you would have to scrape. Here each row carries the merchant, the price, the total including shipping when shown, the offer link and Google’s typical price range.

Do I need a product id?

No. If you have one from the Google Shopping collector, pass product_id for an exact match; otherwise pass a product name as query and it is resolved to the first shopping result for that market.

How fresh are the prices?

They are read at request time from the live product page — there is no cached price index behind this. That is why a run costs money per delivered offer rather than a flat monthly fee: every call is real work through the residential network.

How much does it cost to track 100 products daily?

At roughly a dozen offers per product, about 1,200 delivered offers a day — around $2.40 at the $0.002 list price, less on a volume tier. Products whose page returns nothing that day deliver zero rows and cost zero.

Can it track prices over time?

It returns the current offer list; history is what you build by running it on a schedule and storing the rows. If you would rather not own that loop, competitor price monitoring is the managed version with the scheduling included.

Does it work outside the US?

Yes — set country and, where useful, lang. Sellers, currency and shipping totals are all market-specific, so the same product id in two countries is legitimately two different offer lists.

Should I pass a query or a product id?

A query is convenient for ad-hoc lookups and is resolved to its first shopping result. 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 — and a silent change of subject is the worst failure a price series can have.

What is typical_prices for?

It is Google's own sense of the normal range for the product, which makes it a cheap sanity check: an offer far outside it is worth flagging rather than acting on.

Start with the Price comparison API

$0.002 per delivered offer, $2 per 1,000 delivered offers. $2 of free credit every month, no card — and a run that delivers nothing is never billed.

Get my free API key