Scrapfly Pricing: Cost per 1,000 Pages

Credit pricing is honest but it is not simple. Scrapfly publishes every multiplier, which is more than most vendors in this category do, and it still takes a spreadsheet to answer the only question a buyer has: what will 100,000 pages cost me this month. The answer depends less on which plan you pick than on how many of your target pages need a browser to build their content.

Everything below was read from the Scrapfly pricing page and its billing and Anti Scraping Protection documentation in August 2026. No aggregator numbers, because aggregators are stale on this category within weeks.

Scrapfly pricing tiers

Five tiers, all metered in the same API credit unit. Concurrency and the overage rate are the two things that change most between them.

One line in that table is worth stopping on. Pro is $100 for a million credits and Startup is $250 for two and a half million. Both are exactly $0.10 per 1,000 credits. Moving from Pro to Startup does not make a page cheaper. It buys concurrency, 20 requests in flight up to 50, and it halves the overage rate from $3.50 to $2.00 per 10,000. Size the plan for throughput and for the month you burst, not in the hope of a volume discount that is not there.

How many credits does a Scrapfly request cost?

One credit buys a plain HTTP fetch through a datacenter proxy. Every capability you add on top has a published multiplier, and they stack.

The 6 is the number that matters. Most sites a data team wants in 2026 are client rendered, so the realistic default is a rendered page, not a plain one. Budgeting on 1 credit per page and discovering you spend 6 is the single most common way teams get this wrong, and it is a factor of six, not a rounding error.

What does Scrapfly cost per 1,000 pages?

Divide the plan price by its credits, then multiply by the credits your typical request burns. Here is that arithmetic done for the three request shapes most teams actually run.

All figures are per 1,000 pages and assume you consume the whole allowance. Partial consumption raises the effective rate, because the plan is a commitment rather than a wallet. A team on Pro that uses 300,000 of its million credits is paying $0.33 per 1,000 credits, not $0.10.

Is Scrapfly cheaper than a flat-rate crawl API?

Below a certain share of JavaScript pages, yes, clearly. Above it, no. The break-even is arithmetic rather than opinion, so it is worth doing once for your own mix. Scrapfly costs the plain rate multiplied by (1 + 5f), where f is the fraction of your pages that need rendering. Set that equal to a flat per-page price and solve.

Against our own published rates, which are $0.78 per 1,000 pages on Hobby, $0.40 on Startup and $0.27 on Scale with rendering included at no multiplier, the crossovers land here:

• Discovery against Hobby: break-even at about 84 percent JavaScript pages. Scrapfly wins for most small workloads.
• Pro against Startup: break-even at 60 percent. Below three in five rendered pages, credits are cheaper.
• Enterprise against Scale: break-even at about 39 percent. At high volume, flat pricing takes over much sooner.

Notice the direction. The more you scale, the earlier flat pricing wins, because a per-credit rate barely improves past Pro while a flat page allowance keeps dropping. If you want the same sum run against every vendor in the category rather than just these two, the web scraping API pricing comparison works through cost per 1,000 pages for each one.

Why is the Scrapfly overage rate higher than the plan rate?

Because the plans are volume commitments and overage is not. Discovery buys credits at $0.15 per 1,000 and bills spillover at $0.50 per 1,000, roughly 3.3 times the committed rate. Pro is the widest gap at 3.5 times. Startup is 2 times and Enterprise about 1.3 times, so the penalty shrinks as the commitment grows.

Two practical consequences. First, a bursty workload should be sized against its peak month, not its average, because one heavy crawl can cost more in overage than the plan upgrade would have. Second, Free and Discovery cannot spill over at all: they hard cap. That is the right default for evaluation and the wrong one for anything with a deadline, since the job stops rather than costing more.

Does Scrapfly charge for failed requests?

No. Under the documented Scrape Failed Protection policy, failed scrapes are not billed. There is one exception written into the same policy: if more than 30 percent of your traffic fails inside a single hour, that usage becomes billable under a fairness rule. For anti-bot work this is a genuinely good deal, because on hard targets a meaningful share of attempts will fail no matter whose infrastructure you rent, and paying only for successes changes the economics.

It also explains why the Anti Scraping Protection layer is priced the way it is. ASP is free on pages that are not blocked, so leaving it enabled across a mixed target list costs nothing on the easy pages. On blocked pages the cost fluctuates with the protection in front of the target, and Scrapfly states plainly that the figure can move if a site adds or changes its anti-bot vendor. It may also override your configuration and upgrade you to a better or target-specific proxy pool.

That last sentence is the one to budget around. A request you wrote as 1 credit can be served on residential and bill 25, without you changing a line of code, because the target changed. It is the correct engineering behavior and it makes a forecast a range rather than a number.

What does the Scrapfly Crawler API return?

Gzipped WARC or HAR. Scrapfly does have a real recursive Crawler API that starts from seed URLs, follows links, and stops on whichever of page_limit, max_depth, max_duration or max_api_credit you hit first. Billing is simply the sum of the underlying scrape calls, so the credit table above applies unchanged.

The artifact is the catch for AI teams. WARC is a web archive format and HAR is a network trace, and both are excellent for compliance, replay and debugging. Neither is chunkable. If the crawl was meant to fill a vector store, you still have to unpack the archive, isolate the response bodies, strip the navigation and footers that repeat on every page, and convert to markdown. That preprocessing stage is usually the reason a team went looking for a hosted crawler in the first place. We wrote up the whole trade in the Scrapfly alternative comparison, including the rows where Scrapfly wins.

Which plan should you buy?

Work down these in order and stop at the first that matches.

• Your targets block you. Buy Scrapfly, on Pro or above so overage is possible, and leave ASP on. Nothing in this article argues against that. Unblocking is a specialist product and it is what you are paying for.
• Your targets are permitted and mostly static. Discovery at $30 is very hard to beat at $0.15 per 1,000 pages. Watch the hard cap.
• Your targets are permitted and mostly client rendered. Run the break-even above. Past roughly 60 percent rendered, a flat per-page price with JavaScript rendering included costs less and removes the flag-by-flag cost modelling entirely.
• You need markdown or typed JSON out of a whole-site crawl. Price the preprocessing engineering, not just the credits, because WARC to clean documents is real work that recurs every time the pipeline runs.

The teams that get burned here are the ones that never separate the two purchases. Getting a response from a hostile server and turning a cooperative page into model input are different problems with different vendors, and paying anti-bot prices for documentation sites is as wasteful as pointing a cleaning-focused crawler at a site that will never let it in. Most stacks end up running one of each, and the routing rule is whether the target has ever returned a challenge page.

How to sanity check the bill before you commit

Take 200 URLs that represent your real target mix. Run them twice, once without render_js and once with it, and compare the extracted text length. The share where the plain fetch comes back materially shorter is your f, the fraction that genuinely needs a browser, and it is almost always higher than people guess. Read the X-Scrapfly-Api-Cost header on each response rather than estimating, since it reports what the request actually billed after ASP made its own decisions.

Then multiply out for a full month at your expected volume, add the overage band for your worst week, and put that figure next to the flat-rate quote. If price monitoring or catalog tracking is the workload, the crawl budget should be sized to the refresh cadence the numbers need once they land in a dashboard that unifies your store and channel data, because a daily refresh and an hourly one differ by 24 times on the same page count.

Do the test on frozen URLs and keep the results. Every vendor in this category reprices, and a comparison you can rerun in six months is worth more than one you read once. Ours is on the pricing page and the live extraction console at the top of any page will show you exactly what comes back before you spend anything.