What will I be billed when a scrape is blocked?

A block can cost 0 credits, the ordinary request rate, or a higher automatically selected rate. Firecrawl’s default auto route costs 1 credit when its basic route succeeds and 5 credits when the basic route fails and an enhanced retry succeeds, while Scrape.do does not bill a returned 403 but does bill its published successful response classes (Firecrawl enhanced mode and Scrape.do request costs, retrieved 2026-07-26).

This guide is only about a block encountered during a scrape. The separate failure-billing guide owns the broader explanation of target status codes, provider errors, retries, and plan cliffs.

What each vendor defines as a billable outcome

The table includes every current product record, including search APIs, cloud browsers, and platforms. That wider population prevents a product from disappearing merely because its billing model does not fit a request-based comparison. Quotation marks identify short wording published by the vendor. An unquoted statement is a narrow summary of the linked first-party policy. When the reviewed page does not answer the blocked-request question, the row begins Not published.

What each vendor defines as a billable outcome table

Which block responses count as success?

Do not treat “blocked” as one wire-level outcome. The block-specific decision has three branches:

Which block responses count as success? table

For every Not published row in the full table, the answer remains unknown. A success-only slogan without a status definition does not prove that a challenge page, empty shell, consent wall, or login wall is free.

How anti-bot escalation changes the rate

The billing distinction is timing. Automatic escalation starts with one route and changes it while the provider is handling the request. A preselected mode is already fixed by the client, target profile, or product class before the provider sees whether the basic route would have worked.

Automatic retry or driver escalation inside one request

Automatic retry or driver escalation inside one request table

Server or target class selected before the attempt

These are not mid-request fallback ladders, even when the vendor chooses the class.

Server or target class selected before the attempt table

Client-selected before dispatch

Client-selected before dispatch table

Worked invoice: 1,000 attempts with two kinds of block

ScrapingFish makes the status boundary checkable because its record stores all four inputs needed here: one request unit per billable fetch, a $0.002 rate per charged request, a 1,000-request pack that costs $2, and a billing rule that charges HTTP 200 and 404 but not other failed statuses. The pack expires after one month. (ScrapingFish request and status rules, pack pricing, retrieved 2026-07-26.)

Assume a hypothetical log contains 740 usable HTTP 200 pages, 160 challenge pages that also arrived as HTTP 200, and 100 target 403 responses. These are scenario counts, not a vendor success-rate, speed, or reliability claim. Applying the stored status rule gives:

Worked invoice: 1,000 attempts with two kinds of block table

The challenge rows are billable because their wire status is 200; that is an inference from the published status rule, not a claim about whether ScrapingFish recognizes any particular challenge. The 403 rows are outside its published charged set. (ScrapingFish pricing, retrieved 2026-07-26.)

value of all billable requests = 900 x $0.002 = $1.80
value of billable challenge pages = 160 x $0.002 = $0.32
value estimated from usable pages alone = 740 x $0.002 = $1.48

cash purchase = $2.00 for the 1,000-request pack
unused pack capacity = 1,000 - 900 = 100 requests
cash cost per 1,000 usable pages = $2.00 / 740 x 1,000 = $2.702703

The $1.80 figure is consumed request value, not a second invoice added to the pack. The $2.00 cash purchase covers the 900 billed requests and leaves 100 request units unused. The gap between a usable-page estimate and the purchase comes from both the 160 billable challenge responses and unused pack capacity. (ScrapingFish request and status rules, pack pricing, retrieved 2026-07-26.)

How to instrument your side so you can audit the invoice

Write one immutable event for every outbound attempt. Do not collapse a client retry into the same row as its parent request.

attempt_id
logical_request_id
retry_ordinal
sent_at_utc
vendor
product
account_or_zone
target_domain
target_url_hash
requested_mode
mode_selection_origin
server_profile
automatic_escalation_enabled
observed_final_route
api_http_status
target_http_status
provider_error_code
provider_request_id
observed_vendor_units
semantic_outcome
response_body_hash
cancelled_by_client

Use mode_selection_origin values such as client, server_profile, and automatic_retry. Use your own semantic_outcome values such as usable, captcha, login_wall, consent_wall, empty_shell, target_error, and provider_error. Keeping those fields separate is what reveals a billable HTTP 200 challenge page and prevents a preselected protected mode from being mislabeled as automatic escalation.

Capture the provider’s request-level evidence before a client library discards headers. ScraperAPI publishes sa-credit-cost; Scrape.do publishes Scrape.do-Request-Cost; Scrapfly publishes X-Scrapfly-Api-Cost and context.cost; Cloudflare publishes X-Browser-Ms-Used for Quick Actions. Sources: ScraperAPI, Scrape.do, Scrapfly, and Cloudflare, retrieved 2026-07-26.

Reconcile in the vendor’s native unit before converting anything to dollars:

logged_units
  = sum(observed_vendor_units by vendor, account, day, requested mode,
        selection origin, and observed final route)

invoice_difference
  = invoiced_units - logged_units

For a vendor without a request-level cost field, preserve the two status layers, request identifier, requested features, selection origin, final route, semantic classifier, and body hash. Compare those attempt groups with the vendor’s daily usage export.

The finished ledger must answer four different questions:

1. How many attempts did the client launch?
2. Which attempts changed route automatically, and which started in a preselected mode?
3. How many units did the provider deduct for each final route?
4. How many responses did the application accept as usable rather than merely HTTP-successful?