Do scraping APIs charge for failed requests? What 9 products actually bill

This is what each provider's own documentation said when we checked it on Sep 24 and 25, 2026. Each row links to the page it comes from; the product pages on ScrapeSelect quote the exact wording.

The short version

"Failed request" means the provider could not get a usable response after its own retries. Apify and Browserless are platforms where you run your own browser or crawler, so they bill the time used, not the outcome.

Provider by provider

• Bright Data Web Unlocker. The pricing page says "Pay only for success", but the docs don't list which target statuses count as one. One setting changes the rule entirely: with custom headers, cookies or "expect" elements enabled, "you'll be charged for 100% of the requests (both successful and failed)" .
• Oxylabs Web Scraper API and Web Unblocker. "All responses from the target site with 2xx or 4xx status codes are counted as successful." So a 403 from a site that blocked you is billed, as is a 404. Failures on Oxylabs' side (5xx) are free, but "if a request results in a failed attempt due to a fault or error on your side, you will still be billed." Web Unblocker bills the traffic of those responses rather than a count.
• ScraperAPI. "We only charge for successful requests (200 and 404 status codes) and for requests that have been cancelled from your side before giving us enough time to finish them (70 seconds)." The second half matters if your client times out early: a request you abandon after 30 seconds is billed.
• ScrapingBee. The documentation has the most explicit table: 200, 404, 410 and 413 are billed; 400, 401, 403, 429 and 500 are not.
• ZenRows. "Failed attempts aren't charged, and 404 or 410 responses count as usable results." One exception is in the error-code docs: when the target domain doesn't resolve (RESP007, Site Not Found), the request is billed.
• Zyte API. Bans, rate-limiting and errors are free. Anything else the site returns is a success, whatever its status: a request to a missing page gets "a successful response from Zyte API, where the value of the statusCode response field is 404". A 403 is free when Zyte classifies it as a ban, and billed when the site sends it for another reason.
• Apify and Browserless. These bill resources, not results. Apify charges compute units (1 GB of RAM for an hour) and Browserless charges browser time, so a page that fails still costs the time it took. Browserless also bills 10 units for each successful CAPTCHA solve.

What this means for your bill

• Clean your URL list. Every managed API except Bright Data (which doesn't say) bills a 404. If 10% of the URLs you crawl are dead, roughly 10% of your bill is for pages with nothing on them. Dropping known-dead URLs before sending them costs nothing.
• Blocks cost money on Oxylabs. Because any 4xx counts as a success there, a site that answers with 403 is billed like a page you wanted. On ScrapingBee, ScraperAPI and Zyte (when it is a ban), the same block is free.
• Watch your timeouts. On ScraperAPI, give requests the full 70 seconds; cancelling earlier is billed. On Apify and Browserless, a long timeout on a page that will never load is paid browser or compute time, so the opposite applies: cut losses early.
• Customising requests can change the rules. On Bright Data, sending your own headers or cookies makes failures billable too. Check a provider's docs before turning on options that give you more control.
• Check what was billed. Some providers tell you per request. Bright Data's x-brd-debug header includes a billed=true or billed=false field. Compare a day of your own logs with the provider's usage dashboard before scaling up.

How this feeds into cost estimates

When ScrapeSelect estimates a monthly cost, it uses these rules: for products that bill only successes it counts successful pages, and for products that bill every attempt it adds the retries implied by the success rate. The calculator shows both, and the 500,000-page comparison shows how much they move the total. If a provider's documentation changes, the change log records it.