Price intelligence infrastructure for developers

Scrapfly vs PricesAPI

Extract products from URLs you choose, or read stored seller offers and price history for a known product.

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

Scrapfly gives you control over acquisition, extraction and recurring callbacks. PricesAPI gives you product-and-market resources with retained observations where coverage exists. Both return structured commerce data; the decision is who collects the pages, resolves product identity and keeps the history.

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	Scrapfly
Free access	Free, one-time: 300 Searches with merchant offers (3,000 credits); 6 rpm	1,000 credits
Entry paid plan	$49/month: 3,000 Searches with merchant offers (30,000 credits); 20 rpm	Discovery $30/month: 200,000 credits; 5 concurrent requests
Input and identity	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.	Supply a URL for scraping, or document content for extraction. Models, prompts and templates do not create a cross-retailer product identity.
Offer response	Snapshot returns seller IDs, listing URLs, amounts and observation timestamps. Check offers_page.truncated; there is no offer cursor.	Scrape + extraction puts product data at result.extracted_data.data. Standalone extraction returns top-level data: supply the document body; its optional URL is context, not a fetch instruction.
Variant prices	A typed product reference does not prove an exact physical variant. Check the seller's listing and product details before comparing prices.	Main offers[].price is a number. variants[].offers[].price is a nullable object with amount, currency and raw; each can also be null. Variant URL and SKU can be null. Check usable fields before comparing or navigating.
Currency, payment and delivery	Snapshot and History currency is inferred from market. Snapshot has no numeric shipping amount; unknown shipping is not free delivery. An item amount alone does not establish outright payment or a checkout total.	The built-in model allows currency inference and free-text delivery, but has no structured shipping charge or payment-basis field. Our integration assessment: a number alone does not establish outright or delivered cost. Custom prompts/templates can request additional fields.
Existing history	Read retained observations before your app began tracking, where coverage exists. Missing days stay missing; a read does not force a refresh.	The linked scrape and extraction APIs do not establish a precollected price-history archive. Store your own repeated observations.
Batch behavior	Snapshot Batch reads up to 100 products with per-item results. History continuation is a separate cursor workflow.	Paid batch accepts 1–100 configurations. Correlation IDs match out-of-order multipart results; inspect each item's status.
Recurring delivery	Schedules (Beta) refresh supported retained data. They are not customer-configured arbitrary-URL webhook jobs.	UTC cron or interval schedules require a webhook. Verify HMAC signatures, acknowledge deliveries and handle retries idempotently.
Billing and failures	10 credits for a Search with at least one merchant offer; Snapshot: 1 per product; History: 1 per day with recorded offers. Searches with no products or no merchant offers, and empty History windows, are free. Known-product Snapshots with zero offers still bill. Not-found products and failed requests are free; other operations have their own billing units. History reserves the requested span, then refunds unobserved days; valid continuation pages add no charge.	Scrape credits depend on selected features; cost headers expose usage. Failed-scrape protection has exclusions, so not every failure is free.

Feature: Free access
PricesAPI: Free, one-time: 300 Searches with merchant offers (3,000 credits); 6 rpm
Scrapfly: 1,000 credits

Feature: Entry paid plan
PricesAPI: $49/month: 3,000 Searches with merchant offers (30,000 credits); 20 rpm
Scrapfly: Discovery $30/month: 200,000 credits; 5 concurrent requests

Feature: Input and identity
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.
Scrapfly: Supply a URL for scraping, or document content for extraction. Models, prompts and templates do not create a cross-retailer product identity.

Feature: Offer response
PricesAPI: Snapshot returns seller IDs, listing URLs, amounts and observation timestamps. Check offers_page.truncated; there is no offer cursor.
Scrapfly: Scrape + extraction puts product data at result.extracted_data.data. Standalone extraction returns top-level data: supply the document body; its optional URL is context, not a fetch instruction.

Feature: Variant prices
PricesAPI: A typed product reference does not prove an exact physical variant. Check the seller's listing and product details before comparing prices.
Scrapfly: Main offers[].price is a number. variants[].offers[].price is a nullable object with amount, currency and raw; each can also be null. Variant URL and SKU can be null. Check usable fields before comparing or navigating.

Feature: Currency, payment and delivery
PricesAPI: Snapshot and History currency is inferred from market. Snapshot has no numeric shipping amount; unknown shipping is not free delivery. An item amount alone does not establish outright payment or a checkout total.
Scrapfly: The built-in model allows currency inference and free-text delivery, but has no structured shipping charge or payment-basis field. Our integration assessment: a number alone does not establish outright or delivered cost. Custom prompts/templates can request additional fields.

Feature: Existing history
PricesAPI: Read retained observations before your app began tracking, where coverage exists. Missing days stay missing; a read does not force a refresh.
Scrapfly: The linked scrape and extraction APIs do not establish a precollected price-history archive. Store your own repeated observations.

Feature: Batch behavior
PricesAPI: Snapshot Batch reads up to 100 products with per-item results. History continuation is a separate cursor workflow.
Scrapfly: Paid batch accepts 1–100 configurations. Correlation IDs match out-of-order multipart results; inspect each item's status.

Feature: Recurring delivery
PricesAPI: Schedules (Beta) refresh supported retained data. They are not customer-configured arbitrary-URL webhook jobs.
Scrapfly: UTC cron or interval schedules require a webhook. Verify HMAC signatures, acknowledge deliveries and handle retries idempotently.

Feature: Billing and failures
PricesAPI: 10 credits for a Search with at least one merchant offer; Snapshot: 1 per product; History: 1 per day with recorded offers. Searches with no products or no merchant offers, and empty History windows, are free. Known-product Snapshots with zero offers still bill. Not-found products and failed requests are free; other operations have their own billing units. History reserves the requested span, then refunds unobserved days; valid continuation pages add no charge.
Scrapfly: Scrape credits depend on selected features; cost headers expose usage. Failed-scrape protection has exclusions, so not every failure is free.

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 want stored seller comparisons and earlier observations for products the catalogue already covers.
You want to use the same product reference for seller comparisons and price-history charts.

Choose Scrapfly when

You need acquisition and extraction controls for URLs you select.
You want streamed batches and recurring callback jobs, and will own identity matching and historical storage.

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 Scrapfly · URL → product modelDocumentation: Automatic extraction response

GET https://api.scrapfly.io/scrape
  ?key=YOUR_KEY
  &url=https%3A%2F%2Fretailer.example%2Fproduct
  &extraction_model=product

Abbreviated response; invented values, not executed:
{
  "result": {
    "extracted_data": {
      "content_type": "application/json",
      "data": {
        "name": "Example headphones",
        "offers": [{ "price": 129, "currency": "USD", "availability": "available" }],
        "delivery": null,
        "variants": [{
          "color": "Blue", "url": null, "sku": null,
          "offers": [{
            "price": { "amount": 139, "currency": "USD", "raw": "$139" },
            "availability": "available"
          }]
        }]
      },
      "data_quality": { "errors": [], "fulfilled": true, "fulfillment_percent": 100 }
    }
  }
}

A successful scrape can still have incomplete or invalid extraction.
Inspect data_quality and the offer fields your application needs.
Schema fulfillment is not a price-accuracy score; unknown is not zero.

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