Price intelligence infrastructure for developers
DataForSEO vs PricesAPI
Queue a Google Shopping collection, or read a selected product's stored offers and 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
DataForSEO Merchant Google Shopping fits bulk collection with location controls, seller detail and completion callbacks. PricesAPI fits apps that read stored offers and earlier observations by product and market.
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.
- Merchant Google: Standard task workflow
- Products tasks: query, location and depth
- Products result timestamps and retention (freshness checked 2026-10-01)
- Product Info: identifiers (pvf input documentation checked 2026-10-04)
- Product Info: variants and result retention (returned variations checked 2026-10-04)
- Seller tasks: variant filters and depth (pvf input checked 2026-10-04)
- Seller results: amounts, condition and availability (installment fields checked 2026-10-04)
- GID guide: typed identifier example (checked 2026-10-04)
- Merchant billing blocks and priorities
- HTTP and per-task status codes (retry row checked 2026-10-01)
- Failed-task billing and retention FAQ
| Feature | PricesAPI | DataForSEO |
|---|---|---|
| Free access | Free, one-time: 300 Searches with merchant offers (3,000 credits); 6 rpm | Merchant tasks spend a prepaid balance. See the official pricing source for current account terms; task/result units differ from PricesAPI credits. |
| Entry paid plan | $49/month: 3,000 Searches with merchant offers (30,000 credits); 20 rpm | Prepaid usage depends on task type, result blocks and priority. See Merchant pricing for the units used by your workflow. |
| 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. | Discover by keyword and location/language. Product Info and Sellers accept product_id, data_docid or gid; use available IDs together. Integration inference: keep identifier type, exact value and market; do not assume these IDs map directly to PricesAPI catalog IDs. |
| Seller and condition | Snapshot gives seller_id, domain and listing title/URL. Condition is not exposed on Snapshot or observed History; listing equivalence still needs checking. | Seller results include seller_name, domain, listing URL, product_condition and product_availability. Product Info returns specifications and variations with IDs. Sellers documents pvf as a variation filter; Product Info does not document pvf input. |
| Delivery and totals | 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. | Seller results separate base_price, tax, shipping_price and total_price. Missing values need interpretation; some examples pair null shipping with free-delivery wording. Check price_multiplier and displayed_payment_breakdown for installment terms before comparing monthly payments with outright prices. |
| Currency | Snapshot and History currency is inferred from the requested market, such as USD for market=us. Compare item prices within the same market. | Seller results include an ISO currency code. The docs label some amounts integer but show decimals; do not reinterpret these values as minor units. |
| Freshness | Search no_cache=true bypasses stored results but may share an in-flight collection. Snapshot is a retained read: it does not trigger a fresh scrape. Inspect observation time and stale state; neither operation confirms the seller's current checkout price. | A task requests collection; priority affects its queue. Result datetime records receipt, not the merchant's price-change time. Retrieving the same task again does not request new collection. The reviewed Products contract establishes no cache-bypass control. |
| History | Read retained offer observations with requested-window coverage. Missing days stay gaps; history depth varies by product and market. | Completed task results can be retrieved for 30 days. This retention is not evidence of precollected product-price history for dates before your task. |
| Pagination and batch | Snapshot caps at 60 offers, with a truncation flag and no offer cursor. Batch accepts 100 products; History pages repeat the original request tuple. | Submit up to 100 tasks per POST. depth controls collection within a task, not a history cursor; Sellers documents a maximum of 200 results, not guaranteed coverage. |
| Asynchronous work | Snapshot and History read stored data. Async Bulk Search is a separate discovery workflow, not a History export. | Merchant Google uses Standard POST → task ID → GET, with polling, pingback or postback. Do not apply other DataForSEO products' Live endpoints to this workflow. |
| 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 empty Snapshot still bills. | Products: blocks of up to 40 results; Sellers: up to 10; Product Info: per task. Priority changes the price; get_shops_on_google doubles the seller-task cost. Result retrieval is free within retention. |
| Failures | 404 means unknown identity, 403 insufficient balance, 409 expired History cursor, and 429 includes Retry-After. A fresh History restart can bill again. | HTTP 200 can contain task failures: inspect status_code at both levels. Partial-result code 40106 excludes unreturned pages from charging; 40202 means the request-rate limit was exceeded. |
| Pacing and retries · checked Oct 1 | Limits are per account, not per key. For rate-only 429, honor Retry-After seconds. Over-quota Search retries also return 429: inspect credit details and pause until credit is available, regardless of the delay. | Read body codes, not HTTP alone: 40202 is minute-rate throttling; 40200/40210 concern funds; 40203 is a daily cost cap. 40601/40602 mean pending work. Keep those task IDs and retrieve their results instead of resubmitting the batch. |
- Feature
- Free access
- PricesAPI
- Free, one-time: 300 Searches with merchant offers (3,000 credits); 6 rpm
- DataForSEO
- Merchant tasks spend a prepaid balance. See the official pricing source for current account terms; task/result units differ from PricesAPI credits.
- Feature
- Entry paid plan
- PricesAPI
- $49/month: 3,000 Searches with merchant offers (30,000 credits); 20 rpm
- DataForSEO
- Prepaid usage depends on task type, result blocks and priority. See Merchant pricing for the units used by your workflow.
- 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.
- DataForSEO
- Discover by keyword and location/language. Product Info and Sellers accept product_id, data_docid or gid; use available IDs together. Integration inference: keep identifier type, exact value and market; do not assume these IDs map directly to PricesAPI catalog IDs.
- Feature
- Seller and condition
- PricesAPI
- Snapshot gives seller_id, domain and listing title/URL. Condition is not exposed on Snapshot or observed History; listing equivalence still needs checking.
- DataForSEO
- Seller results include seller_name, domain, listing URL, product_condition and product_availability. Product Info returns specifications and variations with IDs. Sellers documents pvf as a variation filter; Product Info does not document pvf input.
- Feature
- Delivery and totals
- PricesAPI
- 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.
- DataForSEO
- Seller results separate base_price, tax, shipping_price and total_price. Missing values need interpretation; some examples pair null shipping with free-delivery wording. Check price_multiplier and displayed_payment_breakdown for installment terms before comparing monthly payments with outright prices.
- 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.
- DataForSEO
- Seller results include an ISO currency code. The docs label some amounts integer but show decimals; do not reinterpret these values as minor units.
- Feature
- Freshness
- PricesAPI
- Search no_cache=true bypasses stored results but may share an in-flight collection. Snapshot is a retained read: it does not trigger a fresh scrape. Inspect observation time and stale state; neither operation confirms the seller's current checkout price.
- DataForSEO
- A task requests collection; priority affects its queue. Result datetime records receipt, not the merchant's price-change time. Retrieving the same task again does not request new collection. The reviewed Products contract establishes no cache-bypass control.
- Feature
- History
- PricesAPI
- Read retained offer observations with requested-window coverage. Missing days stay gaps; history depth varies by product and market.
- DataForSEO
- Completed task results can be retrieved for 30 days. This retention is not evidence of precollected product-price history for dates before your task.
- Feature
- Pagination and batch
- PricesAPI
- Snapshot caps at 60 offers, with a truncation flag and no offer cursor. Batch accepts 100 products; History pages repeat the original request tuple.
- DataForSEO
- Submit up to 100 tasks per POST. depth controls collection within a task, not a history cursor; Sellers documents a maximum of 200 results, not guaranteed coverage.
- Feature
- Asynchronous work
- PricesAPI
- Snapshot and History read stored data. Async Bulk Search is a separate discovery workflow, not a History export.
- DataForSEO
- Merchant Google uses Standard POST → task ID → GET, with polling, pingback or postback. Do not apply other DataForSEO products' Live endpoints to this workflow.
- 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 empty Snapshot still bills.
- DataForSEO
- Products: blocks of up to 40 results; Sellers: up to 10; Product Info: per task. Priority changes the price; get_shops_on_google doubles the seller-task cost. Result retrieval is free within retention.
- Feature
- Failures
- PricesAPI
- 404 means unknown identity, 403 insufficient balance, 409 expired History cursor, and 429 includes Retry-After. A fresh History restart can bill again.
- DataForSEO
- HTTP 200 can contain task failures: inspect status_code at both levels. Partial-result code 40106 excludes unreturned pages from charging; 40202 means the request-rate limit was exceeded.
- Feature
- Pacing and retries · checked Oct 1
- PricesAPI
- Limits are per account, not per key. For rate-only 429, honor Retry-After seconds. Over-quota Search retries also return 429: inspect credit details and pause until credit is available, regardless of the delay.
- DataForSEO
- Read body codes, not HTTP alone: 40202 is minute-rate throttling; 40200/40210 concern funds; 40203 is a daily cost cap. 40601/40602 mean pending work. Keep those task IDs and retrieve their results instead of resubmitting the batch.
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 need earlier recorded offers without first running and storing a new collection campaign, where product coverage exists.
- You want exact product-and-market reads with item prices, seller delivery text, observation times and explicit history gaps.
Choose DataForSEO when
- You need localized Shopping research across many queries and can process queued results or callbacks.
- Your comparison needs Google's seller condition, availability and tax/delivery fields, with your own checks for missing or inconsistent amounts.
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.
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, not executed. Invented ID and amounts; abbreviated response.
POST https://api.dataforseo.com/v3/merchant/google/sellers/task_post
Authorization: Basic REDACTED
Content-Type: application/json
Request body:
[{"product_id":"1234567890123456789","location_code":2840,"language_code":"en","depth":20}]
Use an ID from discovery for the intended variant. Retain the task UUID.
After completion:
GET https://api.dataforseo.com/v3/merchant/google/sellers/task_get/advanced/TASK_UUID
Authorization: Basic REDACTED
Response fragment:
{
"status_code": 20000,
"tasks": [{
"id": "TASK_UUID",
"status_code": 20000,
"result": [{
"datetime": "2026-09-20 12:00:00 +00:00",
"items": [{
"type": "shops_list",
"seller_name": "Example Store",
"base_price": 80,
"tax": 8,
"shipping_price": 5,
"total_price": 93,
"currency": "USD",
"product_condition": "New",
"product_availability": "in_stock"
}]
}]
}]
}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.