ScraperAPI vs ScrapingBee: General-Purpose Scraping APIs Compared (2026)

ScraperAPI and ScrapingBee both charge 1 credit for a plain HTML request, 10 for a premium proxy, and 25 for the two together. Then one of them charges 10 credits to render a page and the other charges 5. That one line is most of what separates two products that otherwise sell the same shape of thing: one endpoint, a URL in, HTML or structured JSON out, with proxy rotation, retries and anti-bot handling hidden behind the request.

Credits are where the decision actually lives, because the formula quietly settles whether a given crawl costs $100 or $1,000 a month. This piece compares ScraperAPI and ScrapingBee on that arithmetic, on what each publishes about its own plans, and on the endpoints each ships for common targets. Every price and credit figure below was read off the vendors' own pricing pages and documentation on 27 July 2026.

The credit formula, side by side

ScraperAPI's credits and requests page and ScrapingBee's API documentation each publish a table. Put them against each other and the overlap is striking.

Most of that table is identical. Plain requests cost 1 credit on both, premium proxies cost 10 on both, and premium plus rendering costs exactly 25 on both. Two companies with no reason to coordinate landed on the same numbers, which tells you how settled this market's pricing has become. Our guide to scraping API credit pricing covers why the formulas converged.

The rows where they diverge carry the whole decision.

Rendering is the 2x fork

ScraperAPI charges 10 credits to render a page. ScrapingBee charges 5. Everything else about the two credit tables is close enough to ignore, so a workload's rendered share is the single variable that moves the answer.

Work an example. Take 1,000,000 pages a month, 90 percent of which are static HTML and 10 percent of which need a browser:

• ScrapingBee: 900,000 plain requests at 1 credit, plus 100,000 rendered at 5, is 1,400,000 credits.
• ScraperAPI: the same 900,000 at 1 credit, plus 100,000 at 10, is 1,900,000 credits.

That is a 36 percent gap in credit consumption on a workload that is only one tenth rendered. Push the rendered share to a third and the gap widens sharply. Push it to zero and the two are identical: a crawl that is entirely plain HTML costs the same number of credits on either vendor, and the decision moves entirely to plan list price.

There is a counterweight, and it favors ScraperAPI. ScrapingBee's default is render_js=true, so an integration that never sets the flag pays 5 credits for every request, including the static ones. ScraperAPI's default path is the 1 credit one, and rendering is opt in. If your team is small, moves fast and does not audit its own request parameters, ScraperAPI's default is the forgiving one. Credit overruns from a flag nobody set are one of the more common ways a scraping budget goes sideways.

Domain surcharges versus separate endpoints

Hard targets are where the two vendors stop agreeing, and most feature tables miss it.

ScraperAPI prices by domain on its general endpoint. Its documentation lists e-commerce (Amazon) at 5 credits, SERP (Google, Bing) at 25 credits, and social media (LinkedIn) at 30 credits. Send a Google URL to the standard endpoint and you are charged 25 credits whether or not you asked for anything special. That is a 25x multiplier applied automatically by target, which is either sensible pricing of a genuinely harder job or an unpleasant surprise on your first invoice, depending on whether you read the docs first.

ScrapingBee's published credit table has no domain multiplier. Its answer to the same problem is a set of prebuilt endpoints: Google Search, Amazon, YouTube, Walmart, ChatGPT and Gemini. The Google Search API accepts search, search_type for web, news, maps or images, country_code, a light_request mode described as faster and cheaper, and pass-through Google parameters such as gl, hl, num and start. It returns parsed JSON with organic results, featured snippets, knowledge graph, local results, ads and related searches. What that documentation page does not state is the credit cost per call, so it would be wrong to conclude ScrapingBee's SERP work is cheaper than ScraperAPI's 25 credits. It may be. Ask before you model it.

If SERP data is the main workload rather than a side quest, neither of these is the natural first stop. The SERP APIs category covers vendors built only for that job, and SerpApi is the usual reference point. Our guide to localized SERP collection goes into why search results are priced apart from general scraping in the first place.

The hardest targets

Both vendors sell a tier above premium for sites running serious bot detection. The pricing shapes differ.

ScraperAPI's ultra_premium is 30 credits, rising to 75 when combined with rendering. ScrapingBee's stealth proxy is a flat 75 credits and, per its documentation, requires JavaScript rendering. There is no cheaper stealth option without a browser.

For a target that is hard to reach but serves usable HTML without a browser, ScraperAPI's 30 credits is less than half of ScrapingBee's 75. For a target that needs both stealth and a browser, the two land on 75 and the choice is a wash. ScraperAPI also documents bot protection bypasses for Cloudflare, Cloudflare Turnstile, DataDome and PerimeterX at 10 credits each, which is a more granular way to price the problem than a single stealth switch. Background on what these systems actually do is in the anti-bot system glossary entry.

ScrapingBee's compensating feature here is mode=auto, which its docs describe as selecting the cheapest working configuration and charging accordingly at 0, 1, 5, 10, 25 or 75 credits. Failed requests cost nothing. For a crawl with a mixed and unpredictable target list, that is a well-designed default: you stop guessing which pages need stealth and let the service escalate. ScraperAPI documents a cost control page of its own, but nothing in what we read describes an equivalent automatic escalation ladder.

Failure handling

ScrapingBee's position is simple: failed requests cost 0 credits.

ScraperAPI's is stated more precisely and is worth reading closely. Its documentation says it charges "for successful requests (200 and 404 status codes) and for requests that have been cancelled from your side before giving us enough time to finish them (70 seconds)." Billing 404s as successes is defensible, since fetching a page and finding it gone is work the service actually performed. But if your crawl does link discovery against a large candidate set with a high miss rate, that line item is real and ScrapingBee does not have it. The 70 second cancellation rule matters too if your client library has an aggressive timeout.

Plans and concurrency

The gap here is about disclosure as much as price. ScrapingBee publishes its whole ladder on one page, with concurrency stated for each tier:

Prices exclude VAT. Per credit, that runs from $196 per million on Freelance down to about $75 per million on Business +.

ScraperAPI's documentation is less forthcoming. It states a free tier of 1,000 credits a month with a maximum of 5 concurrent connections. A May 2026 release note announces two Growth tiers for customers needing more than 5M credits a month: Professional at $975 for 10.5M credits and 300 threads, and Advanced at $1,975 for 21.5M credits and 500 threads. Those work out to roughly $93 and $92 per million credits respectively. Hobby, Startup, Business and Scaling plans are referenced across ScraperAPI's own docs, but their prices, credit allocations and thread limits are not published there, so we cannot state them.

At the top of each published ladder ScrapingBee's per-credit rate is competitive with or slightly better than ScraperAPI's Growth tiers, which complicates the usual assumption that ScraperAPI is simply the cheaper high-volume option. What ScraperAPI does have is a higher ceiling: 21.5M credits and 500 threads on a self-serve tier, against ScrapingBee's published maximum of 8M credits and 400 concurrent requests before you have to talk to sales. If your crawl is growing and you would rather not renegotiate, that headroom counts. Sizing the concurrency you actually need is covered in large-scale crawl architecture.

Geotargeting

Both gate country-level targeting behind a mid tier, and the fine print is more restrictive than either landing page suggests.

ScraperAPI's geotargeting documentation states that Hobby and Startup support only regional us and eu targeting, with individual country codes unavailable. Business and higher get the Standard Geo list, which the docs give as au, ae, ar, at, bd, be, br, ca, ch, cn, de, fr, gb, in, jp, kr, mx, nl, no, nz, sa, se, sg, th, tr, ua, uk, vn, za and others, with Enterprise able to request more. Standard geotargeting adds no credit cost. Premium Geo, which extends into residential and mobile locations, is Business and higher with premium=true.

ScrapingBee's pricing page marks geotargeting as available on Business at $249 and above, and not on Freelance or Startup. Its API documentation separately describes country_code in ISO 3166-1 format working with both premium and classic proxies, naming Brazil, India, Mexico, Russia, the United States and the United Kingdom among supported countries. Those two statements are not obviously consistent, and we could not resolve the discrepancy from the public pages. If geolocation is load bearing for your project, get the supported country list for your specific plan in writing.

The practical read: if you need city or ASN precision rather than country, neither of these is the right layer. That work belongs to a proxy network, and Bright Data or its peers are where that conversation goes, as covered in Bright Data vs Oxylabs.

Structured endpoints

ScraperAPI's documentation index lists structured endpoints for Amazon (product, search, offers), Google (SERP, news, jobs, shopping, maps), Walmart (product, search, category, reviews), eBay (product, search) and Redfin (agent details, for rent and for sale listings, listing search), each with sync and async variants. It also documents an asynchronous API with batch requests, a DataPipeline product for scheduled recurring jobs, and Amazon ZIP code targeting.

ScrapingBee's documented prebuilt set is Google Search, Amazon, YouTube, Walmart, ChatGPT and Gemini. Its general endpoint returns HTML, Markdown, plain text, JSON or screenshots, extracts through CSS or XPath rules, and supports natural-language AI extraction in the same call.

ScraperAPI covers more retail and real estate verticals and ships the async and batch machinery that a scheduled crawl of a few million URLs wants. ScrapingBee covers fewer verticals but is the only one of the two with endpoints pointed at LLM chat interfaces, and its AI extraction path means you can go from URL to typed fields without writing selectors. Whether that is worth anything depends on your tolerance for non-deterministic parsing, which we cover in LLM extraction vs selectors.

What each is bad at

ScraperAPI's weak points: rendering at 10 credits is twice its competitor's rate, and if your target mix shifts toward JavaScript-heavy pages your bill moves with it. Domain surcharges of 25 and 30 credits for search and LinkedIn are easy to trip over. Country-level geotargeting is locked behind Business. It bills 404s. Its published plan ladder has a hole in the middle, and a team crossing 5M credits a month faces a $975 entry point at the Growth tier with no documented step in between.

ScrapingBee's weak points: the self-serve ceiling is 8M credits and 400 concurrent requests, so growth means a sales conversation sooner. Stealth costs 75 credits and forces rendering, with no cheaper stealth-only option for targets that are hard but static. render_js=true is the default, so an unconfigured client burns 5x. Freelance and Startup have no geotargeting at all. The service is cloud only with no self-hosted option, which rules it out where scraping infrastructure has to stay inside your own network. Its structured endpoint list is narrower than ScraperAPI's outside of the LLM-facing ones.

Neither is unusual in the category. ZenRows, Scrapfly, Crawlbase and Zyte all sell variations of the same bundle, and the full web scraping APIs category has more. If you would rather own the stack outright, Scrapy vs Crawlee is the other end of that decision.

Who each one is wrong for

ScraperAPI is wrong for the team whose crawl is mostly JavaScript-heavy pages. Paying 10 credits per rendered request against a competitor's 5, on a workload that is majority rendered, is a difference you will feel every month for no capability you are getting in return. It is also wrong for the team that needs country-level geotargeting on a small budget, since that lives on Business and above.

ScrapingBee is wrong for the team whose volume is already large and still climbing. An 8M credit, 400 concurrent ceiling on the published ladder is a real constraint if you are running tens of millions of requests, and ScraperAPI's Advanced tier exists precisely for that shape. It is also wrong for the team scraping targets that are heavily defended but serve static HTML, where the forced pairing of stealth with rendering means paying 75 credits for a browser you did not need.

And both are wrong for the team that has already built its own rotating proxy layer and browser fleet and only needs clean IPs. That team should be buying proxies, not requests. Choosing web scraping tools walks through where that line sits.

Both offer trials, so the practical move is to run them in the same week against your own hardest twenty URLs, with the request parameters you actually intend to ship, then count the credits each one burned and multiply out to your real monthly volume. That number settles it faster than any feature matrix, and it is the one figure neither landing page can give you.