A web scraping API fetches a web page for you through one HTTP call and handles the proxies, browser rendering and anti-bot challenges behind that call. Evaluate one with a trial on your own URLs, not the vendor's demo pages. Use enough of the pages you need, fetch each one several times, and count a request as a pass only when the body contains content that belongs on that page. Then compare cost per passed page, latency on passed pages, and what the vendor does when a site changes. Small trials mislead. In String's Web Data Frontier Benchmark run of September 16, 2026, a random 10-site trial put two providers within 5 points of each other in the wrong order 40% of the time.
You send a URL. The API picks an IP address, often a residential or mobile one for protected sites, and sends a request that looks like a normal browser. It renders JavaScript when the page needs it and gets past bot challenges from systems such as Cloudflare, DataDome, PerimeterX, Akamai and Kasada. It returns the page as HTML, Markdown or extracted JSON. You pay for the calls, not for the proxy network and the browser fleet behind them.
That is also why evaluation is hard. The work the API does is invisible, and it differs by site. An API that passes every retail site in your list can fail every travel site. A buyer comparing e-commerce APIs on r/WebScrapingInsider put it this way: "I don't want to save money on Amazon only to discover that the same provider is expensive or unreliable on Walmart and the smaller sites." Another team on r/webscraping kept three APIs at once, partly "to be able to have a variety of web scrapers for different sites."
The benchmark sends every provider the same 100 bot-protected pages, five attempts each, and counts a pass only when the status is 2xx and the body contains a text string from that page. We used the September 16, 2026 results to test what a smaller trial would have told a buyer.
So a gap of a few points on a small trial is noise. Either test more URLs or treat the close providers as tied and decide on cost, latency and support.
The benchmark harness is open source. Each target is a fixture of name, url and containsText in src/tests.const.ts, and each provider is a small adapter in src/providers/. Replace the fixtures with your own URLs and markers, add the API keys you want to test to .env, and run it. It applies the pass rule above and reports success rate and latency per provider and per site.
These are the questions enterprise data teams raise when they replace an in-house scraping stack:
If the question is whether to replace the in-house stack at all, build vs buy web scraping infrastructure covers that decision.
String's Web Access API passed 97.0% of requests in the September 16, 2026 run, the highest of the 16 providers tested. We run that benchmark ourselves, so treat it as one input and test on your own URLs. The first 5,000 standard requests are free, and you only pay when String returns content. Current rates are on the pricing page, and our security and compliance status is on the trust page.
The benchmark measures bot-protected pages. If your sites have no bot protection, most APIs will pass most requests, and price, latency and output format should decide. For the full ranking on the 100 sites, see best web scraping APIs. For why the pass rule decides what a success rate means, see the web scraping benchmark problem.
A web scraping API is a service that fetches a web page for you through one HTTP call. It handles proxy rotation, JavaScript rendering and anti-bot challenges, and returns the page as HTML, Markdown or structured JSON. You pay per request instead of running proxies and browsers yourself.
Run a trial on your own URLs, not the vendor's demo pages. Fetch each URL several times, count a pass only when the body contains content from that page, and compare success rate, cost per passed page and latency, site by site. Then check billing rules, rate limits, output formats and what happens when a site changes.
Enough to separate the providers you are choosing between. In our September 16, 2026 benchmark run, a random 10-site trial ordered providers within 5 points of each other wrongly 39.5% of the time, and a 50-site trial 26.7% of the time. With a small list, treat close results as a tie.
Send it your own URLs, five times each, over more than one day, and apply your own pass rule: a 2xx status plus a page-specific string in the body. Divide passed requests by all requests. Do not rely on the provider's dashboard, because it may count any 2xx response as a success.
Treat them as one input. Check the pass rule, the target list and whether the harness is public, because those decide what the number means. A benchmark on unprotected pages says little about protected ones. String publishes its harness and raw results so anyone can rerun them, and it is still a vendor-run benchmark.
Success rate and cost per passed page on your own URLs, limits at your volume, what breaks when a site changes and who fixes it, output formats, data handling and security documents, and a migration plan. Run the new service beside the old stack on the same URLs for two weeks or more before you move traffic.
Most providers offer free credits or a free tier. Check whether failed or blocked requests use up those credits, and whether rendering or premium proxies cost several credits per request, because both change how far a trial goes. String gives 5,000 standard requests free and bills only when it returns content.
At least several days. Bot protection can react to traffic patterns over time, so a result from one session may not hold the next day. Fetch each URL on more than one day, and send the same URLs to every candidate in the same window so the comparison is fair.
official_results/benchmark-2026-09-16T01-03-47-074Z.json in the public harness. Sampling analysis by String on September 30, 2026: 23 provider pairs within 5 points, 4,000 random site samples per trial size; per-provider spread from 10,000 random 10-site samples; mixed-outcome cells counted from per-target successCount.README.md, src/tests.const.ts, src/check.ts.