NewString UnraveledResearch powered by data we scrape from the web.Read the latest issue →
← Answers

Web scraping API vs web unblocker vs proxy service

String team · Published September 28, 2026 · Updated November 10, 2026

What's the difference between a web scraping API, a web unblocker and a proxy?

A proxy service sells IP addresses, and everything else stays your job: headers, rendering, retries and CAPTCHAs. A web unblocker is a proxy that also handles anti-bot checks, so you point your existing scraper at it. A web scraping API takes a URL and returns the page as HTML, Markdown or JSON, with the vendor running browsers and retries. Pick a proxy if you run your own scraper, an unblocker to stop blocks without a rewrite, and an API if you would rather send URLs.

The three side by side

The labels are loose in practice. Bright Data's Web Unlocker can be called through a native proxy interface or a REST endpoint, and several scraping APIs also offer a proxy mode. The useful question is who owns the failure when a site blocks you: you, or the vendor.

Proxy service Web unblocker Web scraping API
What you buy IP addresses (datacenter, residential, ISP, mobile) A proxy endpoint that handles anti-bot checks An HTTP endpoint that takes a URL
How you call it Set it as your client's proxy Set it as your proxy, or call its API POST a URL, get content back
Who handles fingerprints, retries, CAPTCHAs You Vendor Vendor
Who runs the browser You Vendor, when the page needs it Vendor, when the page needs it
Typical output Whatever the site sent your client The target page's HTML HTML, Markdown, or structured JSON
Typical billing unit Per GB, or per IP Per successful request Per successful request or per credit

Our open-source benchmark harness shows the interface difference: it calls Oxylabs Web Unblocker as a proxy host and port, and Bright Data's Web Unlocker through a POST /request to a zone.

When each one fits

Pick a proxy service when you already run your own scraper, your targets are mostly unprotected, and you want control over every header and every retry. It is also the right layer when you need a specific IP: a city-level residential exit, a mobile carrier, or a long sticky session. On unprotected sites it is usually the cheapest layer. The cost is engineering time. When a site upgrades its bot protection, your success rate drops and finding out why is your problem. Per-GB billing also charges for every blocked page and every retry.

Pick a web unblocker when you have a working scraper built around a proxy and you want the blocks to stop without a rewrite. You change the proxy address and the vendor takes over fingerprinting and challenge handling. What you give up is control over the request. By default, Bright Data's Web Unlocker manages headers and cookies itself and disregards the ones you send, and turning on custom headers or cookies makes every request billable, successful or not (Bright Data docs). Oxylabs says its Web Unblocker is not designed to be driven directly by Playwright, Selenium or Puppeteer (Oxylabs docs), so a browser-based scraper needs changes too.

Pick a web scraping API when you would rather send URLs than run infrastructure: agent tool calls, pipelines that need Markdown for a model, or a small team that should not maintain browser fleets. You depend on the vendor's success rate, and that rate varies more than most buyers expect. If the real question is whether to run any of this yourself, see build vs buy for web scraping infrastructure. If you start from a question rather than a URL, you need a search API first: see web search API vs web scraping API.

Should I add a web unblocker just for the sites that cause most of my failures?

Yes, if your own scraper handles most of your targets, because routing only the failing domains to a managed layer is the cheapest way to stop the blocks. Keep the scraper and its proxies on the easy sites. Send the domains that fail most to a vendor that bills per successful request, so you stop paying for blocked pages and retries on exactly the sites that produce them.

Which vendor matters more on those sites than overall success rates suggest, because the hard sites are where the products differ most. In our October 30, 2026 benchmark, Bright Data's unblocker failed all five attempts on 11 of 100 protected sites and Oxylabs' failed all five on 26. Both failed completely on the same 5 sites: temu.com, mouser.com, us.louisvuitton.com, ticketmaster.com and emag.ro. A vendor that ranks well on average can still fail your worst domains.

To choose, do this:

  1. List the domains that account for most of your failures, and the protection vendor on each if you can tell.
  2. Run 5 attempts per domain through each candidate, the way our benchmark does, and count the sites where all 5 fail.
  3. Pick the vendor with the fewest total failures on your list, not the best average.
  4. Check what the proxy-style unblockers take over. Bright Data's Web Unlocker ignores the headers and cookies you send by default, and turning them on makes every request billable. Oxylabs' Web Unblocker is not designed to be driven by Playwright, Selenium or Puppeteer, so a browser-based scraper needs changes.

A scraping API is the lower-change option for this split when the hard sites are a small share of your traffic: you send those URLs to one endpoint and leave the rest alone, with no proxy settings to rework. String failed all five attempts on none of the 100 sites in the benchmark. It still lost some individual attempts, so test it on your own list as well. If a hard site also needs a specific IP, such as a city-level residential exit, that part still belongs to a proxy provider.

What the managed layer adds, measured

On October 30, 2026 we ran 17 managed products, scraping APIs and unblockers both, against the same 100 protected sites: 5 attempts per site, 500 requests per provider, 90-second timeout. Overall success ran from 27.6% to 98.6%.

Product tested Type Success Requests passed Mean latency
String Scraping API 98.6% 493 / 500 4.24 s
Bright Data Web Unlocker Unblocker 75.4% 377 / 500 27.88 s
Oxylabs Web Unblocker Unblocker 67.4% 337 / 500 16.62 s

The per-site data shows where the gaps are. In the October 30, 2026 run, Bright Data's unblocker failed all five attempts on 11 of the 100 sites, and Oxylabs' failed all five on 26. On 32 sites, at least one of the two returned nothing in five tries. Both failed completely on the same 5 sites: temu.com, mouser.com, us.louisvuitton.com, ticketmaster.com and emag.ro. String failed all five attempts on none of the 100 sites. It still lost some sites: on yellowpages.com and marketwatch.com both unblockers passed all five attempts and String passed 4, so no product wins every site.

The protection vendor matters too. On the 19 sites behind DataDome, in the October 30, 2026 run, Bright Data's unblocker passed 74.7%, Oxylabs' passed 67.4% and String passed 97.9%. No single site in the set passed on every attempt for all 17 products, and 95 of the 100 sites had at least one product that failed all five attempts.

We did not benchmark a raw proxy. A proxy has no success rate of its own, because the result depends on the scraper you run through it. The full leaderboard and per-site table are on the benchmark page, and the best web scraping APIs comparison ranks the field.

Where String fits

String is a web scraping API. The Web Access API takes a URL and returns the page as Markdown, raw HTML or a JSON envelope. Each request starts as a plain fetch on a standard proxy and escalates to browser rendering, premium proxies, or CAPTCHA solving only when the target needs it. Pricing is per 1,000 successful requests: as of October 2026, on the $99 Growth plan, $0.16 for a plain fetch and up to $3.25 when a page needs both a browser and a premium proxy. The first 20,000 standard fetches are free. If you need a raw IP pool to run your own scraper, String is the wrong product and a proxy provider is the right one. For vendor-by-vendor detail, see String vs Bright Data and String vs Oxylabs.

FAQ

What is the difference between a web scraping API and a proxy service?

A proxy service sells IP addresses that you route your own requests through, and you handle headers, rendering, retries and CAPTCHAs yourself. A web scraping API takes a URL and returns the page as HTML, Markdown or JSON, with proxies, rendering and retries handled by the vendor. The proxy gives you control; the API takes the work, and the vendor owns the block.

What is the difference between a web unblocker and a scraping API?

An unblocker keeps the proxy interface: you point your existing scraper at it and the vendor handles fingerprints and challenges. A scraping API replaces the interface with an HTTP call that takes a URL. The line is blurry, since some unblockers also have REST endpoints and some scraping APIs have proxy modes. In our October 30, 2026 benchmark, Bright Data Web Unlocker passed 75.4% of 500 requests and Oxylabs Web Unblocker passed 67.4%.

Do I need a proxy provider or a full scraping API?

Choose a proxy if you already run a scraper, your targets are mostly unprotected, or you need a specific IP type such as a city-level residential exit or a sticky session. Choose a scraping API if you would rather send URLs than maintain browsers and retries, or if an agent or pipeline needs clean content. If your scraper works but gets blocked, an unblocker changes the least code.

Which is cheaper, a proxy or a scraping API?

On unprotected sites, a proxy is usually cheaper. On protected sites, per-GB billing charges for blocked pages and retries, and the engineering time to keep success rates up is often the larger cost. Scraping APIs and unblockers usually bill per successful request. As of October 2026, String charges $0.16 to $3.25 per 1,000 successful requests on the Growth plan, depending on whether a page needs a browser or a premium proxy. For how that mix works out on real protected pages, see how to reduce web scraping costs.

Does String sell proxies?

No. String is a web scraping API. It uses standard and premium proxies internally and escalates to them per request, but it does not sell raw IP access.

Sources

Get your API key →Explore the Web Access API