Home / How we work out what a scraping API costs

How we work out what a scraping API costs

Every figure here is either copied from a vendor's own page or computed from figures that were. The receipt beside a result shows the inputs, arithmetic, source URLs and retrieval dates needed to check it.

6 sections74 products, 273 plans, 219 metersLatest recorded source date 2026-07-26Reviewed

What is compared, and what is not

We compare scraping APIs, SERP APIs, cloud browsers, AI extraction APIs and agent-facing search APIs on what a described monthly workload would cost to buy.

Eligibility is decided before price. Products are only compared when they can serve the same described job, including its required product class and concurrency. A cloud browser billed by session time and a scraping API billed per request do not return the same thing. If a product cannot serve the job, it receives no price and is shown as not supported.

Raw proxy plans are out of scope. Proxy consumption appears here only where it is how a scraping product meters you.

Where the numbers come from

Plan prices, included allowances, overage rates and billing rules are read from the vendor's own pricing page and billing documentation. Every factual vendor claim carries the source URL and retrieval date. Every computed result carries those sources into its receipt.

First-party documentation always outranks a third-party comparison. Where a vendor's pricing page and its own docs disagree, we record both and show the conflict rather than picking the one that reads better.

We do not run benchmarks. This site does not state or imply that one vendor has a better success rate, speed or reliability than another.

Turning a job into a bill

Vendors bill in units they invented: credits, requests, successful results, browser minutes, proxy megabytes, CAPTCHA attempts, tokens. A rate is meaningless without its billing unit, so every rule we hold records what is consumed and what it is consumed per.

The selection rule is simple: the bill is the minimum over every eligible purchase option. The engine prices each plan whose allowance covers the job, each smaller eligible plan plus its published overage, and pay as you go where offered. It then chooses the lowest complete bill. It never assumes that the first plan large enough to cover the job must be cheapest.

Worked example: Browserbase Developer is $20 per month for 100 browser hours with $0.12 per additional hour. Startup is $99 for 500 hours. For a 200-hour job, Developer costs $20 + (100 x $0.12) = $32, so the smaller plan plus overage beats the larger $99 plan by $67. The engine therefore returns $32, even though Developer's included allowance does not cover the job. Source URL: https://www.browserbase.com/pricing. Retrieved 2026-07-26.

The workload count means successful outputs the reader wants to keep. Attempts are every submitted try needed to produce those outputs. If a vendor bills failed requests, the engine divides the wanted outputs by the stated success-rate assumption and prices the resulting attempts. If the vendor bills only successful outputs, it prices the output count instead.

The success rate is one uniform workload assumption applied identically to every vendor. It is never a per-vendor number. A per-vendor rate would be a benchmark claim about reliability, and this site runs no benchmarks. The assumption is shown because it can change consumption, the selected plan and the final bill.

How current these prices are

Every vendor record carries the date a person read that vendor's published page, and that date is printed wherever the figure appears. Nothing on this site is presented as live: a price here is a dated reading of a published page, and the date is part of the claim.

Every guide figure that names a vendor is checked against the dated vendor price stored with the page. A figure that no longer matches must be explained by the shown arithmetic or another cited vendor fact; otherwise the page is not published. This check does not mean the vendor page was freshly revisited.

A change is reviewed by a person before it becomes a price. A rate is never rewritten from an automated read, because a fetch that fails or returns an anti-bot challenge is a failed fetch and not a price change, and many of these vendors sell anti-bot technology and run it on their own sites.

The latest vendor-link check is summarized at the top of every page. Prices that could not be confirmed stay visible only as dated context and are excluded from rankings. Bulk downloads remain unavailable until reuse rights are explicit.

Anything older than 90 days is marked stale rather than presented as current.

What we will not guess

Where a vendor does not publish a price, the cell says so and links to their page. It is never estimated, never averaged from competitors, and never left blank.

A bounded result is excluded from every cheapest claim. If one vendor is at least $10 and another is exactly $20, the unknown first total could be $11 or $100. The lower bound proves a floor, not which vendor comes first.

An assumption-dependent bill is one whose arithmetic closes only after a missing rule is filled with a stated assumption. For example, if a required feature has no published multiplier, the engine may treat it as included and mark that receipt line as an assumption. This is a useful answer to the described scenario, but it is not evidence that the vendor is cheapest. Exact bills with assumptions are excluded from market-wide cheapest claims.

Every result has one of four states. The state tells the reader how much the published evidence can support:

  • Exact: the published inputs produce a complete numeric bill for an eligible offer, and no cheaper unresolved lower bound blocks it. Exact describes the arithmetic. Any assumptions are still disclosed separately.
  • Bounded: published inputs prove the bill is at least the displayed amount, but an unpublished price or rule prevents a complete total.
  • Quote required: no eligible self-serve offer can be fully priced for the job, and the remaining vendor route requires a custom quote.
  • Not supported: the product cannot serve the described job, no published billing rule matches it, a rate lacks a usable billing unit, or no eligible published offer covers it. The engine returns the reason instead of inventing a number.

Corrections

Price and rule changes are recorded with their date and what moved, so a figure you cited last month can still be explained.

If a number here is wrong, tell us which page and which figure and we will check it against the vendor's own documentation and correct it with a dated note. We do not quietly overwrite a figure that was published.

Last materially reviewed: