Web Unblocker, Scraping API or Your Own Browser Fleet: Where the Line Is

ScraperAPI's published credit table charges 1 credit for a plain request and 75 for a rendered request on its top proxy tier. That is a 75x spread inside a single vendor, set by flags rather than by the plan you signed. It is wider than the gap between most vendors' headline prices, and it does not show up until the second invoice.

Three product categories claim the same job: get a page back from a site that does not want to give it to you. Web unblockers, scraping APIs and browser infrastructure integrate differently, bill differently, and get described with the same vocabulary in vendor marketing. That leaves the buying decision resting on copy rather than on where the boundary sits.

Everything below that carries a number was read from the vendor's own documentation or pricing page on 27 July 2026. We run no benchmarks and make no claims about anyone's success rate or latency. Where a vendor's page was unreachable, the guide says so rather than filling the gap.

The three categories, defined narrowly

A web unblocker is a proxy endpoint that also solves challenges. You keep your HTTP client, your crawler and your parsing. You change one thing: the upstream proxy. Options travel as HTTP headers because a proxy request has no body to put them in. Oxylabs documents its Web Unblocker at unblock.oxylabs.io:60000, with geolocation passed through an x-oxylabs-geo-location header and rendering through X-Oxylabs-Render, and its Python sample sets verify=False to skip the certificate check, since the endpoint terminates TLS in order to inspect and retry.

A scraping API is a request-response service. You send a URL and a set of parameters, and you get back HTML, JSON or extracted fields. Because the vendor controls the whole request lifecycle, it can retry internally, escalate from a plain fetch to a rendered browser session, parse the result into a schema, and bill you only when something usable comes back. The web scraping API category is the largest of the three and by far the most crowded.

Browser infrastructure is remote Chrome. You connect Puppeteer or Playwright to somebody else's browser pool, or you run the pool yourself. Nothing is abstracted. You still write the navigation, still handle the challenge, still bring proxies. What you buy is capacity and the absence of a machine to patch. Browserless is the long-running example, running managed Chromium, Firefox and WebKit over WebSocket with an open-source core that can be self-hosted under a commercial licence.

Those three descriptions differ in what the vendor is responsible for, and the billing unit tracks that responsibility: per success where the vendor owns the outcome, per gigabyte where it owns the transport, per browser-second where it owns nothing but the CPU.

What the billing unit tells you

Nobody prices on an outcome they cannot control, so the billing unit shows you where a vendor has drawn its own line. It is a better guide than the feature grid.

Those five rows come from pages we read directly. Four vendors in this guide could not be checked the same way on 27 July 2026: ZenRows returned 403 to a plain fetch of its pricing page, Scrape.do moved the docs URL we tried, and Zyte and Scrapeless were not reached in the budget for this page. All four describe credit or per-success models in their own marketing, and all four are reasonable candidates, but take the multipliers from their docs rather than from any round-up, including this one.

Two of the verified rows deserve unpacking, because they are where the marketing and the contract diverge.

Bright Data markets Web Unlocker on paying only for success, and its docs say plainly that you are charged only for successful requests to your target domain. Its configuration page is equally plain about the exception: turn on custom headers and cookies and "you'll be charged for 100% of the requests (both successful and failed)", on the stated grounds that Bright Data no longer has full control over the process and its performance. That matters more than it sounds. Custom headers are what you reach for on the hardest targets, which is exactly where your failure rate is highest. The protection switches off at the moment it would be worth the most.

Scrapfly states that failed scrapes are not billed, and names the three failure classes it absorbs: target 5xx responses, anti-scraping-protection challenge failures, and network timeouts. It then documents a fairness policy. If more than 30 percent of your traffic returns eligible error codes within a one-hour window, billing resumes for that window. That is a defensible clause, and it is stated in the open, but it draws a line you want to know about before pointing a crawler at a target you have never tested. Scrapfly also exposes a cost_budget parameter that caps the credits a single request may spend, which is the closest thing in this market to a circuit breaker on a runaway call.

Success-based billing is real wherever it is advertised, and it is bounded wherever it is advertised too. Find the bound before you plan capacity around it.

What an unblocker is actually for

The case for a web unblocker is narrow and strong. You already have working crawler code, and a subset of your domains started returning challenges.

Because the endpoint is a proxy, integration is a configuration change. Oxylabs describes Web Unblocker as a backconnect proxy compatible with existing proxy infrastructure, needing only credential and endpoint updates. In practice that means Scrapy takes a proxy value in request meta or a downloader middleware, and Crawlee takes a proxy configuration object. Spiders, item pipelines and scheduling stay as they are. If your team has years of accumulated crawl logic in a crawling framework, the unblocker is the option that does not ask you to throw it away.

The case against is equally specific. An unblocker returns a page, not a schema, so you still own parsing. It gives you thin visibility into what it did on your behalf, so debugging a persistent failure means reading response headers and inferring. And Oxylabs bills the product by the gigabyte, which means a rendered page that fails a challenge three times still costs you the bandwidth of four page loads. On its product page on 27 July 2026, the entry Micro plan listed at $9.40 per GB, shown as $5.64 per GB with a promotional code applied. The number will move. The unit will not, and the unit is the part that decides who eats a bad day.

That difference is worth checking inside a single vendor's catalogue, not just across vendors. Oxylabs sells more than one product against this problem, and they do not share a billing unit, so confirm which one a quote actually covers before you compare it to anything.

An unblocker is the wrong choice if you have no existing crawler. You would be buying the hardest part of the problem, anti-bot handling, and keeping the second hardest, parsing and retry orchestration, for yourself. Start with an API instead.

It is also the wrong choice if your workflow drives a real browser. Bright Data's Web Unlocker docs state that the product is not intended for browser-based automation or third-party browser tools such as Adspower, Puppeteer, Playwright or Multilogin, and direct those users to its Browser API. Reading that sentence before you architect around it saves a sprint.

What a scraping API adds, and what it costs

The scraping API earns its margin on four things the unblocker does not do: headless rendering on demand, internal retry and escalation, structured extraction, and per-success billing.

Rendering is where most of the money goes, and vendors price it as a surcharge rather than a flat rate for a reason. ScraperAPI publishes the clearest table of the group. A plain request is 1 credit. render=true is 10, premium=true is 10, the two together are 25, ultra_premium=true is 30 on paid plans, and ultra_premium with rendering is 75. Named bot-protection bypasses, including Cloudflare, Cloudflare Turnstile, DataDome and PerimeterX, are 10 credits each. Some domains carry fixed costs regardless of flags: Amazon at 5 credits, Google and Bing at 25, LinkedIn at 30.

The practical consequence is that your effective price per page is set by the share of your targets that need a browser, not by the headline plan price. At ScraperAPI's published rates a crawl that renders every page on the top proxy tier costs 75 times one that does neither. Teams that sample their target list and set rendering per domain rather than globally cut their bill substantially. Teams that set render=true once in a shared config and forget about it do not.

The anti-bot systems on the other end are why the surcharge exists and why it stops being optional on certain domains. A vendor quoting one blended rate has averaged across a target mix that is not yours.

Beyond ScraperAPI and Scrapfly, the category is deep. ZenRows sells a universal scraper API alongside a hosted scraping browser and its own residential proxy pool, which is useful when you want one vendor for both layers. Scrape.do pairs a general endpoint with prebuilt per-site endpoints that return structured JSON for common targets. Zyte comes from the team that maintains Scrapy and has the deepest integration with it, which matters if your orchestration already lives there. Scrapeless bundles a scraping browser, a universal API and a proxy network in one account. We did not verify any of their current prices for this guide, so treat those as capability notes and get the numbers from the vendors.

A scraping API is the wrong choice for stateful work. If a task requires logging in, holding a session across a dozen navigations, filling a multi-step form or reading state written by one page and consumed by another, a per-request API makes you rebuild that state on every call, and you pay the rendering surcharge each time to redo work you already did. That is the signal to move up to browser infrastructure.

It is also the wrong choice, or at least an overpriced one, for search results. A dedicated SERP API is built for that request shape and generally undercuts a general-purpose endpoint that applies a 25-credit domain surcharge to the same page.

What owning a browser fleet actually costs

The self-run fleet is the option teams most often talk themselves into, and the one where the quoted price is furthest from the real one.

What you get is complete control. Your fingerprints, your Chrome version, your proxy vendor, your retry policy, your logs. For a team with an unusual requirement, that control is the whole point. Air-gapped deployments, residency rules that forbid sending target URLs to a third party, or automation whose behaviour is itself proprietary all point here and nowhere else.

What you pay comes in three parts. First, compute billed by time rather than outcome. Browser infrastructure is metered on the clock even when you rent it. Browserless defines a unit as a block of browser time of up to 30 seconds per browser connection, with another unit for every additional 30 seconds, and it counts a session reconnect as a new browser connection carrying a fresh unit charge. Its pricing page adds 6 units per MB of residential proxy traffic, 2 units per MB of datacenter traffic, and 10 units per successful CAPTCHA solve. Every one of those is charged whether or not the page you wanted came back.

Second, proxies as a separate contract. A browser fleet does not include IPs. You buy from a proxy network on top, which means a second vendor relationship, a second bill, and the ongoing work of choosing residential against datacenter pools per target. The rotation policy that works on one site fails on the next.

Third, and largest, the rota. Detection moves. Anti-bot vendors ship updates on their own schedule, and the failure mode is a success rate that decays over weeks rather than an outage that pages someone at 3am. Somebody on the team owns noticing that. Somebody owns the Chrome upgrade that changes a TLS signature. That salaried time is the real price of the fleet, and it appears on no invoice, which is exactly why the option looks cheaper than it is.

A fleet is the wrong choice below roughly a million requests a month on ordinary targets. That threshold is judgement rather than measurement, but the shape holds: at low volume the API bill is smaller than one engineer's fractional attention, and you have bought an operational surface for no saving. It is also wrong for any team without a named owner. A fleet with no maintainer works for a quarter and then quietly stops, and the pipeline downstream fills with empty results before anyone notices.

A decision path

Work through these in order. The first match is your answer.

Does the task need a persistent session? Logins, carts, multi-page forms, anything where step three depends on state from step one. If yes, stop here. You need browser infrastructure or your own fleet, and the per-request categories will fight you the whole way. Rent from Browserless or a peer before you build.

Do you already have crawler code that works, with a minority of blocked domains? If yes, an unblocker is the cheapest fix available, because the change is a proxy line. Route only the blocked domains through it and leave the rest on your existing transport. Budget by bandwidth if the vendor bills by GB, and assume failed attempts still cost you.

Is your target list mixed, with most pages plain HTML and some needing a browser? This is the majority case and it is what scraping APIs are built for. Set rendering per domain rather than globally, and let per-success billing absorb the tail. Scrapfly, ScraperAPI, ZenRows and Scrape.do are all reasonable entry points. Differentiate on the fine print, not the headline rate.

Is every target hostile and the volume large? You are in enterprise territory, where the questions become concurrency limits, contractual handling of failures and account management rather than price per thousand. Bright Data and Oxylabs both sell here, and the Bright Data vs Oxylabs comparison covers how they differ. Expect a sales cycle.

Is compliance the constraint rather than cost? Then self-hosting is the path, and the question is whether you license a commercial build such as Browserless's or assemble one from open-source parts. Either way, staff it properly.

The middle is where most teams land

On paper the three categories read as alternatives. Most production setups run two of them at once.

One frequent shape: a crawling framework for orchestration and scheduling, a scraping API for the domains that fight back, and plain requests for the ones that do not. Another: browser infrastructure for a handful of stateful workflows, and a per-request API for the bulk crawl. Another: an unblocker under an existing Scrapy deployment while a longer migration happens in the background. If you are one level up from this decision and still choosing between categories, the guide to choosing a scraping tool covers that fork.

Mixing works because the cost driver is the share of requests that need a browser, not the logo on the invoice. An architecture that lets you set rendering per domain beats one that forces a single global setting, whichever vendor sits underneath. So instrument the split before you sign anything. Measure what fraction of your target list actually requires JavaScript, rerun that measurement quarterly, and let the number pick the product.

A caution on evidence. Independent benchmark projects that publish periodic success-rate and latency comparisons are worth more than a vendor's own numbers, and worth more than a table like the one above, which reports prices and says nothing about performance. They are still a snapshot of one target set on one date, and vendors quote the runs that flatter them. Test on your own targets before committing, because your target mix is the variable that decides the bill and nobody else has measured it.