Do Scraping APIs Charge You for Failed Requests?

Almost every scraping API says it charges only for successful requests. The sentence is nearly meaningless on its own, because each vendor defines success differently. ScrapingBee bills a 200, 404 or 410. Oxylabs bills every 2xx and 4xx, so a 403 block is billable. Firecrawl bills any page it returns to you.

That is the finding, and it took reading eight vendors' own documentation to get to it. Everything below is quoted from the vendor's published page, read on 2026-09-12, with a link to each one at the end. Nothing here comes from a comparison article, because every comparison in this category is published by one of the vendors being compared.

Do scraping APIs charge for failed requests?

Most say no, and most mean something narrower than you will assume.

The promise is close to universal marketing copy. "Pay only for successful results." "Never pay for failed requests." "We only charge for successful requests." When most of a category makes the same promise in the same words, the promise has stopped carrying information, and the only thing left worth reading is the definition underneath it.

There are two definitions that matter, and they cost different amounts.

The dead-URL question. If you request a page that no longer exists and the site returns 404, is that a success? Almost everyone says yes. ScrapingBee bills "a 200, 404 or 410 status code." ZenRows says "Not Found (404) and Gone (410) responses count as successful results." ScraperAPI bills "200 and 404 status codes." The reasoning is defensible: the vendor did the work, reached the site, and told you the truth about what is there. Budget for it, because a crawl of an old URL list will hit plenty of these.

The blocked-page question. If the site returns 403, or serves an anti-bot interstitial, is that a success? This is the one to ask about, because being blocked is exactly the circumstance in which you retry, and a retry loop against a billable block is the only failure mode in this category that can empty an account overnight.

Which vendors bill for a block?

Published policy, quoted from each vendor's own documentation:

Vendor	Is a 403 block billable?	Their published wording
ScrapingBee	No	"We only charge for successful requests, i.e returning with a 200, 404 or 410 status code."
ZenRows	No	"You only spend credits on successful requests. Not Found (404) and Gone (410) responses count as successful results."
ScraperAPI	No	"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)."
Bright Data	No, by default	"CPM is the cost of 1000 successful requests, meaning only successful Web Unlocker API requests will count toward your billing."
Bright Data, custom headers on	Yes	"when any of the above Custom Web Unlocker API features are enabled, you'll be billed for 100% of the requests (both successful and failed)"
Zyte	Yes, when the block is not a ban	"A Zyte API response is considered successful even in the following scenarios: The response from the target website is a bad response for a reason other than a ban."
Oxylabs	Yes	"All results from the target site with 2xx or 4xx status codes are counted as successful."
Firecrawl	Yes	"This includes pages that come back with an error status such as 403 Forbidden or 404 Not Found."
Apify	Yes, as consumed compute	"The cost of Actor runs depends on the resources used… It also depends on the number of retries when a request fails."
TrueScrape	No	Failed requests, empty results and cache hits are all 0 credits, published on our pricing page

Read the second column against the third. Zyte, Oxylabs, and Bright Data once you send a custom header all publish a success-only promise on one page and a definition on another page under which a block is billable. That is not deception. It is two documents written for two different readers, and only one of them is the one you will be held to.

Why the definition of "success" matters more than the policy

Zyte is the clearest illustration, and to their credit the mechanism is fully documented rather than buried.

Their pricing page says "You are only charged for successful responses." Their error documentation then defines a successful Zyte response as one "with an HTTP status code of 200, when that response provides the requested data, ban-free," and adds that the response is still considered successful when "the response from the target website is a bad response for a reason other than a ban." A target 404 comes back to you inside a Zyte 200 with statusCode: 404 in the body, and it is billed. Rate limiting and genuine infrastructure failures are not billed.

So the policy and the definition point in opposite directions, and both are true. The vendor is charging you for successfully determining that the page is gone.

Oxylabs draws the same line further out. Their Web Scraper API product page carries the line "Pay only for successful results." Their billing documentation says "All results from the target site with 2xx or 4xx status codes are counted as successful," and that failed attempts caused by their own system errors do not count. A 403 is a 4xx. It is billable, it is published, and it sits in plain tension with the sentence on the product page.

What does Firecrawl charge for, exactly?

Firecrawl is the outlier, and it is worth reading carefully because it is also the most honestly documented billing page in the category. They do not claim success-only pricing at all. They publish the rule instead:

"This includes pages that come back with an error status such as 403 Forbidden or 404 Not Found. The target responded, Firecrawl captured that response, and you get it back as a document."

And the other half, which is the fair part:

"A scrape that fails outright, for example because the site never responded or every rendering attempt failed, is not charged."

The test is whether a document came back, not whether the target was happy about it. That is a coherent position: they did the work, they delivered a result, and the result is a fact about the page even when the fact is "you are blocked." Whether it suits you depends entirely on how defended your targets are. On an open site it is indistinguishable from success-only billing. On a hard target it is the most expensive policy in the table.

Two vendors in this set deserve explicit credit for clarity. Firecrawl publishes the aggressive rule plainly instead of hiding behind a slogan. And ScrapingBee publishes the strongest failure guarantee anyone here offers, for its automatic escalation mode: it "tries configurations from cheapest to most expensive, stops at the first one that succeeds, and charges only for that configuration," and "If every configuration fails, the request costs 0 credits." A vendor that tries progressively more expensive configurations and charges nothing when all of them fail has given you something real, and it is better than what most of this table offers, ours included.

Can a success-only guarantee switch off?

Yes, and Bright Data publishes the condition, which most vendors would not.

Their Web Unlocker bills per thousand successful requests by default. Enable certain custom features, including manual headers and cookies or manual "expect" elements, and the documentation says you will be "billed for 100% of the requests (both successful and failed)." Their stated reason is that once you control request parameters, they can no longer take responsibility for the unlocking process.

That is a reasonable trade and an easy one to walk into by accident. Sending one custom header is a small change in your code and a complete change in your billing model. If you are on a plan whose economics depend on not paying for failures, the question to put in writing is not "do you charge for failures" but "under what circumstances does that change."

How much does this actually cost you?

The arithmetic is simple and the result is larger than people expect, because the multiplier is applied to every request, not to the difference.

Take a nominal rate of R per 1,000 requests and a success rate of s. Under success-only billing, your cost per useful record is R/1000. Under bill-every-attempt, it is R ÷ (1000 × s).

Your success rate	Cost premium for billing every attempt
95%	+5%
90%	+11%
75%	+33%
60%	+67%
50%	+100%
30%	+233%

The row you land on is not a property of the vendor. It is a property of your targets. An open site with no anti-bot layer will sit near the top of that table and the billing policy will barely register. A heavily defended social platform can sit near the bottom, and there the policy is the single largest line in your unit economics, larger than the headline rate and larger than the proxy bill.

This is why "which vendor is cheapest" is an unanswerable question in the abstract. Cheapest is a function of your success rate on your targets, and your success rate is a function of which targets you picked. Instagram's official API covers less than most people assume, which is why so many projects end up at a vendor for that platform in the first place, and it is also why those projects are the ones most exposed to failure billing.

How do credit multipliers stack on top of this?

They multiply, which is the part that surprises people.

Failure billing decides whether a request is charged. Credit multipliers decide how much. ScraperAPI charges 1 credit for a normal request, 5 for e-commerce targets, 25 for search engines and 30 for LinkedIn, plus separate parameter costs where ultra_premium=true with rendering reaches 75. ScrapingBee runs 1 to 75 across proxy and rendering combinations. ZenRows charges 5 for JavaScript rendering, 10 for premium proxies and 25 for both.

A blocked LinkedIn request at ScraperAPI would be 30 credits if it were billable. It is not, under their published policy. Under a policy like Firecrawl's or Oxylabs', a blocked request on a high-multiplier target is billed at the high multiplier, because difficulty and failure are correlated: the targets that cost the most per request are the targets that fail most often.

The multiplier arithmetic on its own is worth doing before you buy. Do the failure arithmetic in the same sitting, because separately each one looks like a rounding error and together they are not.

What should you ask before you sign up?

Seven questions. Get the answers in writing, from documentation rather than from a sales call, because documentation is versioned and a sales call is not.

1. Is a 403 or an anti-bot interstitial billable? Not "do you charge for failures." Name the status code.
2. Is a 404 billable? Almost certainly yes. Budget for it and stop being surprised by it.
3. Is a timeout billable, and whose timeout? ScraperAPI bills requests you cancel before giving them 70 seconds. That is published, it is fair, and it will catch any client with an aggressive timeout.
4. What happens when the page loads but the content is missing? A status-code definition of success cannot answer this, because a soft block returns 200 with nothing useful in it. An empty payload is the failure mode that looks most like success, and it is the one least likely to be covered by any refund policy written in status codes.
5. Which settings change the billing model? See Bright Data's custom-header clause. Ask whether any feature flag switches you from success-only to bill-everything.
6. Do retries bill separately? Under a resource-consumption model such as Apify's, retries are pure cost, and the retry count is often set by the actor rather than by you.
7. How is this enforced? A policy in a FAQ is a statement of intent. A creditsCharged field in every response is something you can reconcile against your own logs.

How do you verify a vendor's claim yourself?

Ten minutes, and you do not need an account for most of it.

Find the documentation page rather than the pricing page. The pricing page is marketing and the documentation is the contract. Search the documentation for "404", "403" and "not charged" rather than for "failed", because the interesting sentences are written in status codes.

Then run three requests on a trial: one against a URL you know is 404, one against a target you know blocks datacenter traffic, and one against a URL that times out. Check the balance before and after each. Three requests will tell you more than any comparison table, including this one, because it tests the implementation rather than the prose.

Finally, archive whatever page you relied on. Pricing and billing documentation in this category changes without announcement, and the sentence you based a budget on may not be there in six months.

Where we sit, and what we do worse

We run a social data API, so we are one of the vendors in that table and you should read this accordingly.

Our billing rule is that a failed request, an empty result and a cache hit are all zero credits, and every response carries what it was charged so you can reconcile it. That is not a differentiator we invented. It is what four of the vendors above also do, and ScrapingBee's all-configurations-failed guarantee is stronger than ours on the specific axis this post is about.

Where we are worse: we cover social platforms rather than the general web, so if your crawl targets arbitrary sites, several vendors here are a better fit and we are not a candidate. We charge a multiple of the endpoint price for browser rendering, so we are not multiplier-free either. And we do not offer SOC 2, a signed DPA, or an uptime SLA, which rules us out of procurement processes that require them. Our pricing page publishes the per-request rules if you want to check the paragraph above.

If you take one thing from this, make it the habit rather than the table: the promise is on the pricing page, the definition is in the documentation, and only one of them decides what you pay.

---

Sources, all read 2026-09-12. ScraperAPI credits and request costs · ScrapingBee FAQ and documentation · ZenRows pricing · Zyte API pricing and successful responses · Firecrawl billing · Bright Data Web Unlocker features · Oxylabs Web Scraper API and its billing rules · Apify pricing

Pricing and billing pages in this category change frequently, and more than one vendor here has changed its pricing model recently enough that older comparisons are already wrong. Re-check anything you are about to budget against, and archive the page.