Scraping API Credits Decoded: What a Single Request Actually Costs

On ScraperAPI, the same URL costs 1 credit as plain HTML and 75 credits once the target forces you into ultra premium proxies plus a headless browser. Nothing on the pricing page tells you that. The exchange rate between pages and credits sits in a documentation table, and the pricing page does not link to it. Plans are sold in millions of credits, which makes the headline number look like a quantity of data when what it really measures is work.

That table is where the real price sits. Comparison articles mostly skip it. Proxyway's roundup of the best web scraping APIs prints plan prices side by side without normalising the units underneath them. AIMultiple notes in passing that a credit is not a page, then goes back to listing features.

This guide builds the table those pages leave out. Every multiplier below was read from the vendor's own pricing or documentation page on 27 July 2026, and where a page did not load or did not state a number, this page says so rather than filling the gap. At the end there is a worked example: one monthly workload run through several vendors' published rates. That is arithmetic, not measurement. We run no first-party benchmarks.

If you are still deciding between a managed API, a proxy network and a self-hosted crawler, start with how to choose a web scraping tool instead. This page assumes you have landed on the web scraping API category and now need to compare plans.

The unit problem

Vendors meter in at least five units, and only three of them convert into each other cleanly.

Credits are the most common. A credit is defined by the cheapest possible request and everything else is a multiple of it. The size of the multiple varies by vendor, and on some vendors by target domain.

Requests or results look simpler but hide the same multipliers one level down, because the plan quotes how many results you get using only the basic configuration.

Successful responses shift the definition of billable from what you sent to what came back. Zyte and Crawlbase both bill this way. It is better, but it raises a second question: who decides what counts as success.

Bandwidth, billed per gigabyte, is the standard unit on proxy networks and appears on scraping platforms that expose a cloud browser. Page weight drives cost here, so a retail page with forty images costs several times what a text listing costs regardless of how hard it was to fetch.

Browser hours appear on browser infrastructure products. The cost driver is how long a session stays open, which rewards batching many pages into one session and punishes one page per session.

The first three normalise against each other with arithmetic. The last two do not, because they depend on properties of pages you have not fetched yet, which means a bandwidth quote and a credit quote never land on the same line of a spreadsheet.

The five multipliers

Across credit-priced vendors, the same five levers move the bill.

Base request. A plain HTTP GET through a rotating datacenter proxy. This is the 1 credit reference point on ScraperAPI, ScrapingBee, ZenRows, Scrapfly and Scrapingdog. If your targets are cooperative static HTML, this is the only rate that matters and vendors differ only on the per-credit price.

JavaScript rendering. The vendor boots a headless browser, waits for the page to settle, and returns the DOM after scripts run. ScrapingBee, ZenRows and Scrapingdog price this at 5 credits. ScraperAPI's documentation lists render=true at 10. Scrapfly adds 5 to the base rather than multiplying it.

Premium or residential proxy. Routing through a residential proxy pool instead of a datacenter pool. Priced at 10 credits on ScraperAPI, ScrapingBee and Scrapingdog. This is the lever people underestimate, because it stays invisible until a target starts blocking.

Geotargeting. Requesting an exit IP in a specific country. The common advice is that this is free. That is true on some vendors and false on others, and the difference is large enough to change a ranking. ScraperAPI's credits documentation lists country_code among the parameters that carry no extra cost, alongside wait_for_selector, session_number, device_type, output_format, keep_headers and autoparse. Scrapingdog's pricing page prices geotargeting as its own line item at 10 credits per request, the same rate it charges for a premium proxy. On a workload that is entirely geotargeted, that single row is a 10x difference in base cost between two vendors that otherwise look nearly identical. Check the parameter table, not the feature list.

AI extraction. Passing a prompt or schema and getting structured JSON instead of HTML. This is the weakest-documented multiplier in the category. ScrapingBee's HTML API documentation lists credit costs for rendering and proxy options but states no separate credit cost for its AI parameters. Scrapfly's billing page does not quantify its extraction model either. If you are pricing this seriously, compare it against running your own model over raw HTML, which moves the cost into tokens on a bill you already have. The AI extraction category covers the standalone options.

The normalisation table

Credits per request, read from each vendor's published pricing or documentation page on 27 July 2026.

Sources, all read 27 July 2026: ScraperAPI's credits and request costs documentation page; ScrapingBee's HTML API documentation; ZenRows' scraper API pricing documentation; Scrapfly's scrape API billing page and pricing page; Scrapingdog's pricing page. "Not stated" means the page we read did not give a number, not that the feature is free.

Four things in that table are worth stopping on.

ScraperAPI's stacking is not additive. Premium is 10 credits and rendering is 10, but premium with rendering is 25, not 20. Ultra premium is 30 and rendering is 10, but the combination is 75, not 40. The documentation states the combined figures plainly. They are simply easy to miss, and they mean the hardest requests cost roughly double what a reader summing the parts would expect.

ScraperAPI also prices some domains as a flat rate. Its credits documentation lists e-commerce targets such as Amazon at 5 credits, search engine results from Google and Bing at 25, and LinkedIn at 30, independent of the parameters you set. Screenshots cost 10. Bypassing Cloudflare, Cloudflare Turnstile, DataDome or PerimeterX is listed at 10 credits each. If your workload is mostly search results, the 25 credit SERP rate is your real base rate, and SERP APIs priced per query are worth comparing against it directly.

Scrapfly is additive, which makes it the easiest to forecast. Its billing documentation gives a datacenter request at 1 credit, a residential request at 25, and browser rendering at plus 5, with costs stacking rather than jumping. Residential plus rendering is therefore 30. You can compute any configuration in your head. The exception is its anti-scraping protection: the docs state that ASP dynamically upgrades the proxy pool and browser settings to get through, which raises the cost of the request, and they point to a cost_budget parameter to cap how far it will go. Set that budget, or your cheapest configuration can silently become your most expensive one.

ZenRows publishes prices rather than credits. Its pricing documentation expresses the same 1x, 5x, 10x and 25x structure as dollars per thousand results. On the Business tier it lists $0.10 per thousand basic requests, $0.45 with JavaScript rendering, $0.90 with premium proxies and $2.50 with both. That removes the conversion step entirely, which is the most honest presentation in the group. Its billing rule is also unusually clear: under Adaptive Stealth Mode the docs state you are billed only for the configuration that succeeds and failed attempts are not charged. The flip side is that a mode which escalates until something works gives you a bill you cannot predict per request, only per month.

One vendor is missing from the table on purpose. HasData publishes a multiplier table with an unusual shape, pricing a stealth proxy below JavaScript rendering rather than above it, which would make it structurally cheap for static HTML behind an anti-bot system and structurally costly for JavaScript-heavy targets. Its documentation pricing page did not load for us on 27 July 2026, so we are not printing numbers we could not read today. Pull its rate card yourself before modelling it, and pay particular attention to whether the per-thousand rates on its docs and the credit allowances on its plan pages describe the same tier. Rate cards that are generated per plan are easy to compare against the wrong baseline.

What counts as a billable failure

Every vendor here says some version of "we only charge for successful requests", and every one of them defines "successful" differently.

ScraperAPI's documentation defines it precisely: it charges for HTTP 200 and 404 responses, and for requests you cancel before giving the API 70 seconds to finish. A billable 404 is defensible, since the API did the work and the page genuinely is not there, but it is not what most people assume.

Scrapfly's billing page describes Scrape Failed Protection, under which failed scrapes are not billed. It also documents the limit: if more than 30% of your traffic fails within an hour, on eligible error codes, the protection switches off and the failures become billable. That is a reasonable anti-abuse rule and a serious planning detail. A misconfigured crawler pointed at a hard target can cross 30% quickly, and the protection you were relying on disappears exactly when you are failing most.

ZenRows states that under Adaptive Stealth Mode you pay only for the configuration that succeeds. Zyte charges only for successful responses as its whole model.

None of those definitions covers the failure that actually costs money. A Cloudflare interstitial, a CAPTCHA challenge and a soft block that serves the page with the product grid stripped out all return HTTP 200, so every one of them bills as a success and none of them gives you data. No pricing page can fix that. The only reliable move is to push a few thousand of your real URLs through a free tier and count how many responses contain the field you need rather than how many returned 200.

Then add your retries. If you retry a failed extraction twice, your effective cost per usable page is up to three times the sticker rate on any vendor whose success definition is status-code based. Requests billed divided by pages usable is the only cost figure worth defending in a budget meeting, and no vendor can give it to you.

A worked example

Assume 100,000 pages a month, split the way a mid-sized crawl usually splits:

• 60,000 static HTML pages needing no browser and no special proxy
• 30,000 pages needing JavaScript rendering but tolerating a rotating datacenter proxy
• 10,000 pages behind an anti-bot system needing residential IPs and rendering together

Multiply each bucket by the published rates above. This is arithmetic over published rates as of 27 July 2026. It is not a measurement, it excludes retries, and it assumes every request lands in the bucket you assigned it, which it will not.

The spread is 460,000 to 610,000 credits for identical work, a 33% swing before anyone quotes a price. And credits still are not comparable across vendors, because a credit is worth different money on each.

Converting to dollars needs the per-credit price on the cheapest plan covering the total. We only quote plan prices we read on the day, so this section covers three vendors rather than five.

Scrapingdog. Its pricing page lists Lite at $40 for 200,000 credits with 5 concurrent requests, and Standard at $90 for 1,000,000 credits with 50 concurrent. This workload needs 460,000, so Lite is far too small and Standard covers it with room to spare. The bill is $90, an effective $0.90 per thousand pages of this mix.

Scrapfly. Its pricing page lists Free at 1,000 credits, Discovery at $30 for 200,000 with 5 concurrent, Pro at $100 for 1,000,000 with 20 concurrent, Startup at $250 for 2,500,000 with 50 concurrent, and Enterprise at $500 for 5,500,000 with 100 concurrent. The 540,000 credits this workload needs overshoot Discovery and land on Pro. The bill is $100, an effective $1.00 per thousand pages, and the additive model means you could have predicted that figure exactly before signing up.

ZenRows. Because it publishes dollars per thousand results, no credit conversion is needed. At the Business tier rates: 60,000 basic at $0.10 per thousand is $6.00, 30,000 rendered at $0.45 is $13.50, and 10,000 on premium proxies with rendering at $2.50 is $25.00, for $44.50 of usage. That is the usage figure, not the bill, since it sits inside whatever plan commitment carries those rates, and lower tiers price per result higher.

Plan quantisation does more to the final number than the multipliers do. On Scrapingdog the gap between the $40 and $90 plans is 200,000 credits to 1,000,000. Any workload landing anywhere in that range costs the same $90. A job needing 210,000 credits and one needing 990,000 credits are the same purchase. Optimising your multipliers only saves money when it moves you across a plan boundary.

Concurrency is a second, separate cap

Credits govern how many pages you fetch in a month. Concurrency governs how fast. They are sold together and they bind independently.

Scrapingdog pairs Lite with 5 concurrent requests, Standard with 50 and Pro with 100. Scrapfly allows 5 on Discovery, 20 on Pro, 50 on Startup and 100 on Enterprise. Notice that on both vendors the entry tier is 5, which is the number that catches people.

For a monthly total this rarely binds. Rendering 100,000 pages at fifteen seconds each with five concurrent workers takes roughly 83 hours, which fits inside a month. It binds hard when the crawl has a deadline: a daily price refresh across 50,000 SKUs, or a full re-crawl inside a maintenance window. If freshness is part of the requirement, price the concurrency tier first and treat the credit allowance as the thing you tune afterwards. Large-scale crawl architecture goes further into scheduling around these limits.

The vendors that do not sell credits

Three tools in this guide use units the table cannot express, and for some workloads that is the right answer.

Zyte prices per successful response and classifies every target site into a difficulty tier automatically. Its pricing documentation states that request cost depends on the target website and the features selected, that only successful responses are charged, and it points to a cost estimator. Secondary sources published in mid-2026 put its pay-as-you-go range at roughly $0.13 to $1.27 per thousand HTTP responses and materially more for browser-rendered responses, with lower rates available against a monthly commitment. We did not confirm those tier tables against Zyte's own pages within research budget, so treat that range as reported rather than settled and run the estimator against your real domains.

The structural point holds regardless of the numbers. Zyte assigns the tier, not you. That removes the guesswork about which flags to set and converts it into a rate you cannot know before you start. It suits a long, heterogeneous target list where you would otherwise over-provision for the worst site. It does not suit a procurement process that needs a fixed per-page cost approved before the first request.

Crawlbase also bills per successful request, with two token types on one account: a normal token for static HTML and JSON, and a JavaScript token for pages needing a browser. Its documentation notes there is no separate rendering endpoint. Its pricing page groups the sites you enter by difficulty and prices each group on combined volume through an estimator. The model is usage-based with no monthly floor, which is unusual here. The tradeoff is that the rate card is generated rather than published, so you cannot model a bill without entering your domains first.

Scrapeless meters its browser and crawl products on a hybrid of bandwidth and session time rather than credits. Bandwidth and hours are a different optimisation problem: you win by blocking images and stylesheets, keeping a session open across many pages, and never opening a browser for a page that did not need one. You lose on image-heavy retail pages and on any pattern opening a session per URL. We did not re-read its rate card today, so confirm the current per-gigabyte and per-hour figures before modelling.

Where each option is wrong

Every vendor above suits some workload, which makes the more useful question where each one is a bad fit.

ScraperAPI is wrong when most of your targets are hard. Its 75 credit combined ultra premium and rendering rate is the steepest published multiplier in this group, and a workload that is 80% anti-bot targets drains a million credit plan in roughly 13,000 pages. It is also wrong for SERP-heavy work at 25 credits a query. It is right when the bulk of your volume is plain HTML with a difficult slice, because the 1 credit base carries most of the bill, and it is right for geotargeted work, since country_code costs nothing extra.

ScrapingBee is wrong for teams that will not audit their request parameters, because its own documentation says rendering is the default and costs 5 credits. Every static page fetched by an integration that never sets render_js=false is billed at 5x. Give it to a team that sets flags per domain and the 5 credit rendering rate is among the cheaper ones here.

Scrapingdog is wrong for geotargeted collection, and this is the clearest single finding on this page: its pricing table charges 10 credits per request for geotargeting, the same as a premium proxy, where ScraperAPI charges nothing. A fully geotargeted static crawl costs 10x more on Scrapingdog than the headline base rate implies. It is right for ungeotargeted mixed workloads, where $90 per million credits is the lowest published rate we confirmed. For localised work, read localized SERP collection before choosing a vendor on price alone.

ZenRows is wrong when you need a per-request cost you can predict, because Adaptive Stealth Mode escalates configurations until one works and you learn the multiplier after the fact. It is right when you want to model monthly cost without a conversion step, and its "only the successful configuration is billed" rule was the most customer-favourable billing definition we read on 27 July 2026.

Scrapfly is wrong for residential-heavy workloads, where the 25 credit base applies to every request rather than as an add-on, so a fully residential crawl starts at 25x before any feature. It is also wrong if you leave ASP uncapped, since the docs are explicit that it upgrades parameters and raises cost. It is right when forecasting matters more than the last few cents, because additive pricing lets you compute any configuration exactly.

Zyte and Crawlbase are wrong when you need a number before you start. Both make sense once your target list is long and varied enough that a credit plan would have you buying for the worst site on it.

Scrapeless is wrong when you fetch one page per session, because hourly billing has poor duty cycle under that pattern. It is right when a single browser session walks many pages, which is the shape of most authenticated crawls.

The procedure, in short

1. Export your URL list and tag every domain with what it actually requires: no browser, browser, browser plus residential proxy, geotargeted or not. Do this by testing, not by assuming. The static bucket is always smaller than the first estimate.
2. Pull each vendor's multiplier table from its own documentation, with today's date noted. These change without announcement, and pricing pages and docs pages sometimes disagree.
3. Multiply and sum to get monthly credits per vendor.
4. Find the cheapest plan covering that number and divide the plan price by your page count. That is your real cost per thousand pages, not the headline rate.
5. Check the concurrency on that plan against your freshness requirement. Entry tiers are commonly 5 concurrent requests.
6. Run a few thousand real URLs through each free tier and count usable extractions, not HTTP 200s. Divide billed requests by usable pages and apply that factor to step 4.
7. Ask the two questions no pricing page answers: do unused credits roll over, and what happens when you exhaust the plan mid-month, whether that is a hard stop, an overage rate or an automatic upgrade.

Step 6 is the one people skip and the one that changes the ranking. A vendor 30% cheaper on paper that needs two attempts per page is not cheaper. Our notes on assembling a scraping stack cover how this decision fits alongside the rest of the tooling choices.