By the fastCRW team · Competitor pricing verified 2026-05-18 · Verify independently before buying.
Disclosure: we build fastCRW, a scrape API, not a proxy reseller. That shapes this guide: for the extreme end of hostile anti-bot targets that need a dedicated residential IP pool at massive scale, a specialist proxy provider is the right tool, and we say so plainly below. For everything else — including most JS-challenge and mid-tier anti-bot targets — fastCRW's own built-in anti-bot and proxy rotation cover it. Treat the ranking as a buyer's map, not a sales pitch.
How proxy API pricing actually works for web scraping
If you are searching for the best proxy API for web scraping, the first thing worth understanding is that "proxy API" pricing is not one model — it is three, and the one a vendor leads with is rarely the one that decides your bill. Before you can rank anything by cost, you have to normalise these models against your own traffic shape.
Per-GB vs per-request vs per-success
The three dominant meters are:
- Per-GB (bandwidth). You pay for every byte that flows through the proxy — HTML, images, fonts, the lot. Cheap for small text pages, brutal for media-heavy sites or anything that loads multi-megabyte JavaScript bundles. Residential pools almost always price this way.
- Per-request. You pay a flat amount per fetch regardless of payload size. Predictable, but the headline rate usually applies only to easy datacenter requests; harder targets carry multipliers (see below).
- Per-success. You pay only for requests that return a 2xx. Attractive on hostile targets where failure rates are high, but the per-success unit price is set high enough that the vendor still wins on average.
The practical takeaway: a per-GB quote and a per-request quote cannot be compared until you know your average page weight and your success rate on the specific domains you scrape. A $3/GB residential pool can be cheaper or 10x more expensive than a $1-per-1,000-requests datacenter API depending entirely on whether you are scraping 30 KB product pages or 4 MB single-page apps.
Residential vs datacenter vs ISP
Proxy type drives both price and success rate:
- Datacenter — cheapest, fastest, easiest to detect. Fine for unprotected or lightly protected sites.
- Residential — real consumer IPs, hardest to block, most expensive (typically priced per-GB and several dollars per GB at smaller commitments).
- ISP / static residential — residential-looking IPs hosted in datacenters; a middle tier on both price and stealth.
The cost ranking flips depending on which tier a target forces you into. A site that is happy with datacenter IPs is an order of magnitude cheaper to scrape than one that demands residential rotation.
Hidden multipliers and premium-domain surcharges
This is where published "cost ranked" tables quietly fall apart. Many scraping/proxy APIs apply credit multipliers for hard targets: as a documented example, ScrapingBee charges a base rate for plain HTML requests but escalates to 5 credits for JavaScript rendering, 25 credits for premium proxies, and 75 credits for stealth proxies (marketing/competitor-profiling.md, verified 2026-05-18). A "1 credit" headline becomes a 75-credit reality the moment you hit a Cloudflare-protected page. So any honest ranking has to ask not "what is the base price" but "what is the price on my hardest target, at my success rate."
Proxy APIs ranked by cost (and where the ranking breaks)
Rather than print a stale price table that will be wrong by the time you read it, here is the cost structure by category, ordered roughly cheapest-to-most-expensive for a typical mixed workload. Always confirm live rates — proxy pricing changes constantly and most vendors negotiate at volume.
| Tier | Typical meter | Best for | Cost gotcha |
|---|---|---|---|
| Datacenter-first budget proxies | Per-request or per-GB, low base | Unprotected / lightly protected sites at volume | Block rate on hardened targets makes effective per-success cost spike |
| Mid-tier scraping APIs (ScrapingBee-class) | Per-request credits with multipliers | Mixed targets, some JS rendering | 5/25/75-credit multipliers for premium/stealth/JS-rendered |
| Residential-heavy enterprise (Bright Data, Oxylabs-class) | Per-GB residential | Hostile anti-bot at scale | Bandwidth meter + minimums; page weight, not page count, drives the bill |
Datacenter-first budget options
Cheapest on paper and the right call when your targets do not fight back. The risk is that the published per-request price assumes a high success rate you will not see on protected domains — a 40% block rate silently raises your real per-success cost by 1.67x.
Residential-heavy enterprise providers
Bright Data and Oxylabs anchor the top of the market on proxy depth — Bright Data alone markets a 400M+ IP pool (marketing/competitors.md). That depth is exactly what you are paying for, and on a hardened e-commerce or social target it is worth it. The cost model is bandwidth-led, so a heavy page is an expensive page regardless of how little data you actually wanted from it.
Where pricing gets opaque
The multiplier tiers are the trap. A vendor can rank #1 on a "cheapest proxy API" list using its base datacenter rate and still produce the highest bill in your account, because your workload lives in the 25- or 75-credit premium lane. Read the multiplier table, not the hero number.
Do you even need a proxy API?
The most expensive proxy is the one you did not need. A large share of scraping jobs that reach for residential proxies actually fail for a different reason: the page is JavaScript-rendered and the scraper never executed the JS. That is a rendering problem, not an IP-reputation problem, and no amount of residential bandwidth fixes it.
Many sites need rendering, not residential IPs
If a page returns empty or partial HTML, ask first whether it is a single-page app that needs a browser to render — not whether your IP is blocked. Swapping in a headless renderer is far cheaper than escalating to a residential pool, and it resolves a large class of "the proxy isn't working" tickets.
A scrape API with rendering covers most jobs
A scrape API that renders JavaScript and returns clean output handles the bulk of real-world targets at a fraction of residential cost. fastCRW's auto renderer, for instance, selects an engine per request with a chrome → lightpanda → http fallback (), so most pages resolve on the cheap http/lightpanda path and only escalate to a full Chrome render when the page demands it — every renderer costs the same flat 1 credit. For the cost mechanics of rendering vs. proxies, see anti-bot and proxies overview.
When proxies are genuinely required
Proxies earn their cost when the target actively fingerprints and blocks you: hardened e-commerce, social platforms, ticketing, sneaker sites, anything behind aggressive Cloudflare or DataDome configurations at volume. On those targets, IP reputation and rotation are the bottleneck, and a dedicated proxy provider is the right tool. Be honest with yourself about whether your targets are in that bucket — most are not.
fastCRW's place: a scrape API, not a proxy vendor
fastCRW is deliberately not in the proxy ranking above. It is a Firecrawl-compatible scrape/crawl/map/search API () that competes on output quality and predictable cost, not on the size of an IP pool it does not own. Two things make it relevant to a proxy-cost decision.
1 credit = 1 page, no per-GB metering
A standard scrape costs 1 credit per page regardless of renderer — http, lightpanda, or full Chrome all cost the same flat 1 credit — and JSON extraction is that 1-credit scrape plus the LLM token cost, billed as usage-metered LLM credits (). There is no separate proxy plan to buy and no per-GB bandwidth meter to reason about: the managed cloud handles proxying for you. A 4 MB page and a 30 KB page cost the same, which removes the single biggest source of proxy-bill unpredictability. Compare that flat model against per-GB proxy economics in the cost of web scraping at scale.
Self-host the engine and bring your own proxy
fastCRW is a single static Rust binary under AGPL-3.0 (~8 MB image, 1 container; ). Self-hosted, it costs $0 per 1,000 scrapes — you pay only for your server — versus roughly $0.83-5.33 per 1,000 scrapes on Firecrawl's hosted tiers (marketing/competitor-prices.lock.md, verified 2026-05-18). If you do need proxies for a subset of hostile targets, you route the self-hosted engine through your own proxy provider and pay that vendor directly, with no scrape-API markup layered on top. That separation — clean scrape layer, your choice of proxy underneath — is often the cheapest architecture for a mixed workload.
fastCRW is a scrape API, not a proxy reseller
fastCRW ships its own anti-bot stack — a 12-signal block-detection classifier, user-agent rotation, stealth fingerprints, and proxy rotation including a residential-proxy egress tier on the managed cloud — wired into the auto escalation ladder (). What it is not is a dedicated proxy reseller with a standalone residential-pool product: if a target needs a massive dedicated IP pool at volume beyond what the built-in rotation covers, bring your own proxy in front of the self-hosted engine, or use a dedicated provider for that specific workload.
Cost decision guide
Rank by the protection level of your hardest target, not your easiest:
- Low / medium protection (most documentation, blogs, public catalogs, news): a rendering scrape API or a self-hosted engine is cheapest. You are likely paying for proxies you do not need.
- Mixed workload: self-host a scrape API for the 90% of easy targets, and route only the hard 10% through your own proxy provider — pay proxy cost only where it is actually required.
- Hostile anti-bot at extreme volume (hardened e-commerce, social, ticketing): pay for a dedicated residential proxy provider. This is where Bright Data's and Oxylabs' proxy depth genuinely wins at that scale. See Bright Data alternatives for that end of the market.
- Cost-floor sensitive: self-hosting the AGPL-3.0 engine puts a hard floor on cost ($0 per 1,000 scrapes plus your server), which a hosted-only or per-GB model structurally cannot offer.
If your decision is mostly about the per-request price of the scrape itself rather than proxies, the companion read is the cheapest web scraping API breakdown.
Where dedicated proxy vendors fit
On the small slice of targets that need a massive dedicated residential pool at volume — city-level geo-targeting, session stickiness across thousands of concurrent sessions — providers built around large proxy pools (Bright Data's 400M+ IPs, Oxylabs' equivalent depth) are the right specialist tool. For the anti-bot and rendering work most workloads actually need, fastCRW's built-in stack (block detection, user-agent rotation, stealth fingerprints, proxy rotation) handles it in the same flat-credit scrape.
Sources
- Competitor proxy multipliers and pool depth:
marketing/competitor-profiling.md(ScrapingBee 5/25/75-credit tiers),marketing/competitors.md(Bright Data 400M+ IPs) - Competitor scrape pricing (verified 2026-05-18):
marketing/competitor-prices.lock.md - Bright Data, Oxylabs, ScrapingBee documentation: brightdata.com/pricing · oxylabs.io/pricing · scrapingbee.com (verify current rates independently)
- fastCRW pricing and repo: fastcrw.com/pricing · github.com/us/crw
Related: Anti-bot and proxies overview · Cheapest web scraping API · Bright Data alternatives · Cost of web scraping at scale