ScrapingBee vs ScraperAPI: Pricing, Rendering and Limits

• Mostly ordinary pages that need JavaScript: ScrapingBee. Rendering costs 5 credits there against 10 on ScraperAPI, and its plans carry more credits per dollar.
• Mostly Google results: ScrapingBee on credits. Its Google API works out to 10 credits a search, while ScraperAPI charges its 25-credit SERP rate.
• Many countries on cheap static pages: ScraperAPI. Its country_code adds no credits, while ScrapingBee only geotargets through premium proxies at 10 or 25 credits.
• Amazon, Walmart or eBay data as parsed fields: ScraperAPI, for its structured endpoints and its documented 5-credit e-commerce rate.
• High concurrency on a small budget: ScrapingBee. Its $49 plan allows 50 concurrent requests; ScraperAPI's $49 plan allows 20.
• Pages that do not fight back at all: neither. Plain proxies are cheaper, as covered in web scraping API vs self-managed proxies.

Both vendors publish monthly plans. ScraperAPI also shows a 10% discount for annual billing. ScrapingBee's page lists no annual option and states that prices exclude VAT.

Read from scrapingbee.com/pricing and scraperapi.com/pricing, September 2026. ScraperAPI also lists an Advanced tier at $1,975 and custom Enterprise pricing, and its Professional figure was shown alongside a limited bonus credit offer.

Divide price by credits and the gap is plain. ScrapingBee's Startup plan works out to $99 per million credits. ScraperAPI's Startup is $149 for the same million, with half the concurrency. At 3 million credits it is $249 against $299, with 200 concurrent requests against 100.

That is not the end of the comparison, because a credit does not buy the same thing on both platforms. It does mean ScraperAPI has to win on credit weights to win on price.

Two more plan details matter. ScraperAPI's Hobby and Startup plans list geotargeting as "US & EU only", with global country coverage starting on Business at $299. ScrapingBee's plan grid shows geotargeting ticked on every tier, including Hobby, but gates priority support, an account manager and team management to Business and above.

ScrapingBee weights a request by the options you set. ScraperAPI weights it by the options you set and by the site you point it at.

Sources: ScrapingBee documentation credit table and Google API plan grid; ScraperAPI's "Credits and Requests costs" documentation page. Read September 2026.

The ScrapingBee Google figure is derived rather than printed: its Google API page lists 7,500 searches on the 75,000-credit Hobby plan, which is 10 credits a search.

The table explains most real-world bills. ScrapingBee is cheaper wherever a browser is involved on an ordinary site. ScraperAPI is cheaper wherever you need a country and no browser, and for its three flagship retail domains. On the premium rungs the two are identical.

ScraperAPI's domain rates cut both ways. You cannot tune a Google request below 25 credits there, however clever your parameters. But ScraperAPI documents country_code, session_number, device_type, output_format, wait_for_selector, keep_headers and autoparse as free, which ScrapingBee does not match. We went deeper on the domain-rate model in ZenRows vs ScraperAPI, so this post stays on what differs with ScrapingBee.

Here is the single most expensive line in either vendor's documentation. ScrapingBee's render_js parameter defaults to true. A request with only a URL and an API key goes through a headless browser and costs 5 credits.

Many targets do not need that. Server-rendered product pages, news articles, documentation sites and most JSON endpoints return complete content on a plain fetch. If 60% of your traffic is that kind of page and nobody set render_js=false, you are paying five times the necessary rate on the majority of your volume.

ScraperAPI's default runs the other way. A bare request is a plain fetch, and you opt into render=true at 10 credits. The failure mode flips too: teams on ScraperAPI more often under-render and get back empty JavaScript shells, then conclude the site is blocking them.

ScrapingBee offers a partial fix called Auto-Mode. With mode=auto, it tries configurations from cheapest to most expensive (1, 5, 10, 25, then 75 credits), stops at the first that succeeds, and bills only that one. If all fail, the request costs nothing. A max_cost parameter caps how far it climbs, so max_cost=10 never reaches the 25 or 75 credit rungs. Auto-Mode only varies rendering and proxy tier, works only on GET requests, and never adds country, headers or cookies for you.

Auto-Mode is useful for discovery, less so as a permanent setting. Every request that fails the cheaper rungs costs latency while it climbs. Run it for a day, read the Spb-auto-cost response header to see which rung each domain settled on, then hard-code that configuration per domain group. Our guide to scraping dynamic JavaScript websites shows how to tell whether a page needs rendering at all before you pay for it.

This is where the ranking reverses.

ScrapingBee: the documentation describes country_code as premium proxy geolocation, and requires premium_proxy=true or stealth_proxy=true alongside it. So the cheapest geotargeted request is 10 credits without rendering, and 25 with it. A static page that costs 1 credit from anywhere costs 10 from Germany.

ScraperAPI: country_code is documented as adding no cost. A static page from Germany stays at 1 credit. The catch is plan-level: Hobby and Startup are limited to US and EU locations. If you need Japan, Brazil or India, you are buying Business at $299 or higher.

Put numbers on it. Say you need 200,000 static pages a month from French and German retailers, no rendering. On ScraperAPI that is 200,000 credits, inside the $149 Startup plan and within its US and EU coverage. On ScrapingBee it is 2,000,000 credits at the premium rate, which needs the $249 Business plan. A buyer who compared only headline credit prices would pick the wrong vendor here.

If your geo needs are city-level rather than country-level, neither API is the right tool. Our explainer on what geo-targeting means in proxies covers where that granularity comes from.

Both vendors advertise paying only for successful requests. Their definitions of success differ.

ScrapingBee's status table is from its documentation; ScraperAPI states it charges for 200 and 404 responses and for requests cancelled before completing within 70 seconds, with no charge for other status codes. Read September 2026.

The ScraperAPI cancellation rule deserves attention because it punishes a common habit. Plenty of scrapers set a 30-second client timeout and retry. On ScraperAPI, a rendered request that is still working when your client gives up at 30 seconds is billed, and your retry is billed again. Set client timeouts above 70 seconds on ScraperAPI, and treat the retry budget as a cost line. Our write-up on proxy timeouts and retry logic covers sane values.

ScrapingBee's rule has its own quirk. By default it reports its own status code rather than the target's: any 2xx becomes 200, 404, 410 and 413 pass through, and everything else becomes an unbilled 500. That is good for your balance and bad for your logs, because a 403 from an anti-bot page and a 503 from an overloaded site look identical. Pass transparent_status_code=true when you need the real code for debugging. Its default timeout is 140 seconds, adjustable between 1 and 140.

Here is a mixed workload priced with the published weights. The mix and the rung each group needs are illustrative assumptions, not test results. We did not run this traffic through either vendor.

Assumed monthly mix: 150,000 static pages from ordinary sites; 50,000 pages on ordinary sites that need JavaScript; 20,000 Google result pages; 10,000 pages behind Cloudflare that we assume need premium proxy with rendering on ScrapingBee and the bypass rate without rendering on ScraperAPI. No country targeting.

Now change one thing. Leave ScrapingBee's rendering default on for the static group, so those 150,000 requests cost 5 credits each. ScrapingBee's total climbs to 1,450,000 credits and the plan jumps to Business at $249. One missing parameter cost $150 a month and erased most of the price advantage.

Change a different thing. Require German exits on the static group, still unrendered. ScraperAPI's total does not move. ScrapingBee's static line becomes 1,500,000 credits and the total reaches 2,200,000, still inside Business at $249 but no longer cheap. Add French, Italian and Spanish variants of the same pages and ScraperAPI becomes the cheaper vendor by a distance.

The Cloudflare row is the weakest assumption in the table. If those pages clear on ScrapingBee's 10-credit premium rung without rendering, its line drops to 100,000 credits. You cannot know which rung a site needs until you try it.

The fastest way to settle this is to classify a week of your real URLs and run the weights. The script below uses the published figures from the tables above. Edit the mix to match your traffic.

# Credit estimator: ScrapingBee vs ScraperAPI, weights as published September 2026.
# Each row: (label, monthly_requests, scrapingbee_credits, scraperapi_credits)

MIX = [
    ("static, no geo",          150_000,  1,  1),
    ("static, DE exit",               0, 10,  1),   # ScrapingBee geo needs premium_proxy
    ("JS render, ordinary site",  50_000,  5, 10),
    ("Google SERP",               20_000, 10, 25),
    ("Amazon product page",            0, 25,  5),  # assumes premium+JS on ScrapingBee
    ("Cloudflare-protected",      10_000, 25, 10),  # the rung is an assumption, test it
]

SB_PLANS = [(19, 75_000), (49, 250_000), (99, 1_000_000), (249, 3_000_000), (599, 8_000_000)]
SA_PLANS = [(49, 100_000), (149, 1_000_000), (299, 3_000_000), (475, 5_000_000), (975, 10_500_000)]

def cheapest(plans, credits):
    for price, allowance in plans:
        if credits <= allowance:
            return price
    return None  # above the published ladder: talk to sales

sb = sum(n * c for _, n, c, _ in MIX)
sa = sum(n * c for _, n, _, c in MIX)
print(f"ScrapingBee: {sb:,} credits -> ${cheapest(SB_PLANS, sb)}/mo")
print(f"ScraperAPI:  {sa:,} credits -> ${cheapest(SA_PLANS, sa)}/mo")

Two cautions. Concurrency can force a bigger plan than credits do: if you need 150 simultaneous requests, ScraperAPI's cheapest fit is Scaling at $475 regardless of credit use. And ScraperAPI's geotargeting limit on Hobby and Startup is a plan constraint the script does not model, so bump to Business if any country sits outside the US and EU.

The honest summary: ScrapingBee is the better request-level tool, with finer controls over cost per call. ScraperAPI is the better pipeline-level product, with async jobs, scheduling and parsers that keep a data team from writing its own. Which one matters depends on whether engineers or analysts are the main users. For more options on either side, see our ScraperAPI alternatives roundup.

We sell a scraping API in this category, so here are our published numbers without a sales pitch. The SparkProxy Scraping API gives 1,000 free credits with no card. Starter is $49 for 250,000 credits and 50 concurrent requests, Growth $99 for 1,000,000 and 100 concurrent, Pro $249 for 3,000,000 and 200 concurrent, and Scale $599 for 8,000,000 and 400 concurrent. A plain fetch is 1 credit, JavaScript rendering 5, and a screenshot or PDF 10.

Those tiers line up closely with ScrapingBee's, and we also render by default, so the rendering warning above applies to us too: set render_js=false for static pages. We do not publish domain-based rates for search or retail, and we do not sell residential or mobile proxy plans.

Where neither API makes sense, and most traffic is simple pages, our datacenter proxy plans are flat monthly with unlimited bandwidth: Starter $75 for 100 threads through Plus $440 for 1,000 threads, on gateway.sparkproxy.io port 11000 for rotating HTTP and 13000 for SOCKS5. Per-request billing is the wrong meter for easy pages at high volume.

Pick ScrapingBee if your traffic is rendering-heavy or Google-heavy, you need high concurrency on a small plan, and someone on the team will set render_js=false on every static request. It wins the price comparison in most mixes that do not need countries.

Pick ScraperAPI if you need many countries on unrendered pages, you want parsed Amazon, Walmart or eBay data, or your team prefers async jobs and pipelines to tuning per-request parameters. Budget for a higher plan tier, and keep client timeouts above 70 seconds.

If you cannot decide, spend the 1,000 free credits on both with the same 300 URLs, and read the cost headers each returns. An afternoon of that beats any comparison table, including this one.