Price intelligence infrastructure for developers

Bright Data vs PricesAPI

Collect fresh Shopping product data, or read a selected product's stored offers and price history.

Use PricesAPI data to build price comparisons and history views. Coverage varies by product and market; your application handles analysis and pricing decisions.

TL;DR · PricesAPI assessment

Bright Data's prebuilt Google Shopping scraper supports product URLs and keyword discovery without customer-maintained parsers. Choose it for fresh extraction and batch delivery; choose PricesAPI for retained product reads and history charts where coverage exists.

Official-source facts

Reviewed 2026-09-22. Competitor facts below come from these official sources; PricesAPI facts come from our API documentation and pricing rules. Documented fields do not establish coverage, accuracy or performance for your products. We have not run a paid head-to-head benchmark.

Feature	PricesAPI	Bright Data
Free access	Free, one-time: 300 Searches with merchant offers (3,000 credits); 6 rpm	Check current trial terms; this review used public documentation, not a trial account.
Paid access	$49/month: 3,000 Searches with merchant offers (30,000 credits); 20 rpm	PAYG: $1.50 per 1,000 records. Discovery can return many billed records per input; a record is not a search.
Identity and market	Known IDs skip discovery: send id, id_type (pricesapi or catalog), and market directly to Snapshot or History. Free Catalog text search finds candidate products. Name matches do not confirm physical variants, and Catalog summaries do not prove History availability. A cluster is not an exact product ID.	Choose the Shopping dataset, then supply the full Google product url and optional country. Discovery accepts keyword. product_id is not a documented cross-provider identity.
Seller offers and delivery	Snapshot provides seller IDs and URLs. Snapshot and History have no numeric shipping field: price is the item price; delivery_info is seller delivery text (null means unknown, not free). Delivery depends on the buyer's location. Condition is not published on either retained read.	The fuller dictionary documents buying_options and separate item_price, delivery_price and total_price text fields. Per-seller delivery breakdowns and checkout accuracy are not established. The minimal endpoint example uses sellers instead; do not combine the two into one assumed schema.
Variants and price basis · checked Oct 5	Check each offer's title and URL for the intended variant. Snapshot and History publish no offer-condition or payment-basis field; missing terms remain unknown.	Variations are documented, but variant_id and group_id derive from product_id. price is parsed from item text; availability defaults to in_stock for listed products. These values alone do not verify a matching variant, outright price or current stock.
Currency	Snapshot and History currency is inferred from the requested market, such as USD for market=us. Compare item prices within the same market.	The product example has string price and a separate currency code. Seller-level currency provenance is not established by the minimal schema.
Freshness	Snapshot exposes observation time, age and stale state. Reading it does not request a fresh scrape or confirm the seller's current price.	The Google scraper overview promises live, on-demand extraction. A job snapshot_id identifies collection results, not a seller price-change timestamp.
History	Read recorded offers for a date window with explicit coverage. Leave unobserved days as gaps; depth varies by exact product and market.	These scraper endpoints expose collection results, not a documented pre-existing price-history window. The download reference and FAQ both document 30 days of result retention after job completion. Separate Bright Data datasets are outside this comparison.
Pagination and async	Snapshot: up to 60 offers, truncation flag, no offer cursor. History has bound cursors; Batch reads products and Async Bulk Search runs discovery jobs.	The guide recommends 20 inputs or fewer for sync collection; it is not a hard limit. After one minute, a 202 continues as a job. Async downloads use batch_size and part, not Shopping search cursors.
Billing unit	Search Products: 10 credits per response with at least one merchant offer; Product Snapshot: 1 credit per product; Price History: 1 credit per day with recorded offers. History reserves requested days, then refunds days without offers; valid continuations add no charge. A known-product Snapshot with no offers still bills.	Records, not keyword requests or jobs. Discovery collects product details unless discovery-only mode is selected. Do not price twenty returned records as one search.
Failures	Distinguish 404 unknown identity, 403 balance, 409 expired History cursor and 429 with Retry-After. Restarting an expired walk can bill again.	Handle 400, 401, 429 and terminal job failures. A 202 is still running, not a reason to resubmit. The FAQ says incorrect-input failures can be billed.

Feature: Free access
PricesAPI: Free, one-time: 300 Searches with merchant offers (3,000 credits); 6 rpm
Bright Data: Check current trial terms; this review used public documentation, not a trial account.

Feature: Paid access
PricesAPI: $49/month: 3,000 Searches with merchant offers (30,000 credits); 20 rpm
Bright Data: PAYG: $1.50 per 1,000 records. Discovery can return many billed records per input; a record is not a search.

Feature: Identity and market
PricesAPI: Known IDs skip discovery: send id, id_type (pricesapi or catalog), and market directly to Snapshot or History. Free Catalog text search finds candidate products. Name matches do not confirm physical variants, and Catalog summaries do not prove History availability. A cluster is not an exact product ID.
Bright Data: Choose the Shopping dataset, then supply the full Google product url and optional country. Discovery accepts keyword. product_id is not a documented cross-provider identity.

Feature: Seller offers and delivery
PricesAPI: Snapshot provides seller IDs and URLs. Snapshot and History have no numeric shipping field: price is the item price; delivery_info is seller delivery text (null means unknown, not free). Delivery depends on the buyer's location. Condition is not published on either retained read.
Bright Data: The fuller dictionary documents buying_options and separate item_price, delivery_price and total_price text fields. Per-seller delivery breakdowns and checkout accuracy are not established. The minimal endpoint example uses sellers instead; do not combine the two into one assumed schema.

Feature: Variants and price basis · checked Oct 5
PricesAPI: Check each offer's title and URL for the intended variant. Snapshot and History publish no offer-condition or payment-basis field; missing terms remain unknown.
Bright Data: Variations are documented, but variant_id and group_id derive from product_id. price is parsed from item text; availability defaults to in_stock for listed products. These values alone do not verify a matching variant, outright price or current stock.

Feature: Currency
PricesAPI: Snapshot and History currency is inferred from the requested market, such as USD for market=us. Compare item prices within the same market.
Bright Data: The product example has string price and a separate currency code. Seller-level currency provenance is not established by the minimal schema.

Feature: Freshness
PricesAPI: Snapshot exposes observation time, age and stale state. Reading it does not request a fresh scrape or confirm the seller's current price.
Bright Data: The Google scraper overview promises live, on-demand extraction. A job snapshot_id identifies collection results, not a seller price-change timestamp.

Feature: History
PricesAPI: Read recorded offers for a date window with explicit coverage. Leave unobserved days as gaps; depth varies by exact product and market.
Bright Data: These scraper endpoints expose collection results, not a documented pre-existing price-history window. The download reference and FAQ both document 30 days of result retention after job completion. Separate Bright Data datasets are outside this comparison.

Feature: Pagination and async
PricesAPI: Snapshot: up to 60 offers, truncation flag, no offer cursor. History has bound cursors; Batch reads products and Async Bulk Search runs discovery jobs.
Bright Data: The guide recommends 20 inputs or fewer for sync collection; it is not a hard limit. After one minute, a 202 continues as a job. Async downloads use batch_size and part, not Shopping search cursors.

Feature: Billing unit
PricesAPI: Search Products: 10 credits per response with at least one merchant offer; Product Snapshot: 1 credit per product; Price History: 1 credit per day with recorded offers. History reserves requested days, then refunds days without offers; valid continuations add no charge. A known-product Snapshot with no offers still bills.
Bright Data: Records, not keyword requests or jobs. Discovery collects product details unless discovery-only mode is selected. Do not price twenty returned records as one search.

Feature: Failures
PricesAPI: Distinguish 404 unknown identity, 403 balance, 409 expired History cursor and 429 with Retry-After. Restarting an expired walk can bill again.
Bright Data: Handle 400, 401, 429 and terminal job failures. A 202 is still running, not a reason to resubmit. The FAQ says incorrect-input failures can be billed.

Credits, searches and extracted records are different billing units. Compare the work each request does, not just the number included in a plan. The recommendations below are our assessment.

Choice guide · PricesAPI assessment

Choose PricesAPI when

You already chose an exact product and need stored seller offers plus a history window, where retained coverage exists.
You want observation times and explicit coverage, and can handle unknown shipping and market-inferred currency.

Choose Bright Data when

You need fresh Shopping collection or keyword discovery without building a parser.
You need larger collection batches and downloadable results, and will manage job completion and retain your own observations.

Building a price tracker?

Already have a product ID? Use id, id_type=pricesapi|catalog and market directly with Snapshot or History, both in public Beta. Choose the read your app needs; History does not require a Snapshot request.

Find candidates for free. If you need an ID, search by product or seller text and market. Check that the result matches your product. Catalog summaries do not guarantee History availability.
Compare stored seller prices. Read a product’s latest retained offers. Show when each offer was observed; a stored offer is not a live-price guarantee.
Chart recorded prices. Read a date window and follow the remaining pages. Compare a headphone promotion with its earlier recorded prices, leaving unobserved days as gaps.

History reports coverage for your requested window. It first reserves credits for the full window, then refunds days without offers; continuation pages add no charge. Check the billing rules before choosing a long window.

Response shape

Product Search API returns matched products with available merchant offers inline. Carry a result’s product_ref into Snapshot or History; free product lookup is another starting point. Both examples are illustrative and based on the linked contracts; values are not live measurements or current commercial data.

Illustrative PricesAPI response shapeDocumentation: PricesAPI OpenAPI

GET /api/v1/products/search?q=Sony%20WH-1000XM5&market=us

{
  "success": true,
  "data": {
    "query": "Sony WH-1000XM5",
    "market": "us",
    "products": [{
      "position": 1,
      "pid": 100569554,
      "product_ref": { "id": "100569554", "id_type": "pricesapi", "market": "us" },
      "cluster_id": "123456789",
      "catalog_id": "987654321",
      "title": "Sony WH-1000XM5 Wireless Headphones",
      "image": "https://example.com/headphones.jpg",
      "headline_price": 348,
      "headline_currency": "USD",
      "condition_label": null,
      "source": "Amazon.com",
      "multi_store": true,
      "rating": 4.7,
      "reviews": 8523,
      "delivery": "Free delivery",
      "tags": [],
      "nearby_distance_km": null,
      "offers": [{
        "seller": "Amazon.com",
        "seller_url": "https://amazon.com",
        "price": 348,
        "currency": "USD",
        "product_title": "Sony WH-1000XM5",
        "stock_status": "In stock",
        "delivery_info": "Free delivery",
        "url": "https://example.com/product"
      }],
      "offerCount": 1
    }]
  },
  "meta": { "latency_ms": 842, "raw_count": 3, "gid_bearing_count": 2 }
}

Carry product_ref.id, id_type and market to the read you need:
GET /api/v1/products?id=100569554&id_type=pricesapi&market=us
GET /api/v1/products/history?id=100569554&id_type=pricesapi&market=us&from=2026-09-01&to=2026-09-07

Already have a catalog ID? Skip discovery and choose one read:
Snapshot:
GET /api/v1/products?id=987654321&id_type=catalog&market=us
History (no Snapshot request needed):
GET /api/v1/products/history?id=987654321&id_type=catalog&market=us&from=2026-09-01&to=2026-09-07

Snapshot: inspect observation and offers_page.truncated.
History: inspect coverage and follow page.next_cursor with the same parameters.
Null product_ref means no usable product identity; do not substitute cluster_id.

Illustrative Bright Data Shopping · illustrative, not executedDocumentation: Shopping dictionary (checked 2026-10-05); minimal collect reference above

Illustrative, not executed. Invented values; separate response projections.
Replace the example URL with the actual full Google product URL.
POST https://api.brightdata.com/datasets/v3/scrape?dataset_id=gd_ltppk50q18kdw67omz&format=json&include_errors=true
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

Request body:
{
  "input": [{
    "url": "https://www.google.com/shopping/product/12345",
    "country": "AU"
  }]
}

Alternative 202 response: { "snapshot_id": "EXAMPLE_JOB" }
Poll /datasets/v3/progress/EXAMPLE_JOB; download when ready:
GET https://api.brightdata.com/datasets/v3/snapshot/EXAMPLE_JOB?format=json

Independent full-dictionary illustration, not observed output from this request.
Keep price components as text; omitted arrays are unspecified, not empty.
This is not a verified checkout total or a per-seller delivery breakdown.
Full-dictionary fragment:
[
  {
    "product_id": "ILLUSTRATIVE_PRODUCT",
    "item_price": "A$120.00",
    "delivery_price": "A$8.00",
    "total_price": "A$128.00",
    "currency": "AUD"
  }
]

Separate minimal endpoint example; not a combined schema with the fragment above.
The empty example sellers array does not mean no offers.
Response fragment:
[
  {
    "product_id": "12345",
    "title": "Example headphones",
    "price": "179.00",
    "currency": "AUD",
    "sellers": [],
    "specifications": {},
    "url": "https://www.google.com/shopping/product/12345"
  }
]

Try the Product Search API

3,000 free credits, granted once. That covers 300 Searches returning at least one merchant offer at 10 credits each. Searches with no products or no merchant offers, and failed requests, cost nothing. Snapshot and History use different billing units.

Need more? Developer is $49/month for 30,000 credits, with a limit of 20 requests per minute.

Start free →Read /docs