Do SERP APIs Charge for Failed Requests? 9 Providers Compared

Short answer: most major SERP APIs do not charge for failed requests — as of July 2026, eight of the nine providers we checked publish a no-charge or auto-refund policy for unsuccessful calls. The real traps sit one layer deeper: whether an empty 200 is billed (almost always yes), what each vendor counts as “success,” and the one major provider whose public site documents no policy at all.

Whether a SERP API charges for failed requests looks like fine print until you run real volume. At meaningful scale some percentage of calls will time out, hit an upstream error, or come back without usable data — and whether those calls consume paid credits quietly changes your effective price per result. This is the deep dive on that one line of the fine print; for all five buried fee types in one table, see our SERP API hidden costs guide.

Why SERP API requests fail in the first place

Search engines are an adversarial data source. Every provider in this market — whatever its architecture — deals with the same public realities:

• Timeouts. A search that can't complete within the provider's window returns an error rather than hanging your integration forever.
• Upstream instability. Engines change layouts, throttle aggressively during load spikes, and occasionally serve interstitials instead of results. Industry monitoring cited by Traject Data put API downtime up 60% year-over-year between Q1 2024 and Q1 2025.
• Malformed or unserveable queries. Bad parameters, unsupported locales, or a query the engine simply refuses.
• Genuinely empty results. The search runs perfectly and the engine returns zero organic items — rare on head terms, routine on long-tail and site-restricted queries.

A production failure rate of a few percent is normal, which is why the billing treatment of those calls belongs in your provider evaluation next to headline pricing — and why your observability setup should count failures separately from day one. If you have ever debugged a scraper at 3AM, you know failures cluster at the worst times; the billing question is whether those clusters also show up on your invoice.

The three billing philosophies

Every SERP API lands in one of three camps:

1. No-charge / auto-refund. Failed calls either never consume quota or the credits come back automatically. This is now the documented norm: SerpApi, SearchApi, DataForSEO, Traject Data, Zenserp, HasData and Serpent API all publish a policy in this camp.
2. Success-based billing as the product. Bright Data markets “Pay only for success” as a headline feature — “Only pay for successful requests” — with a notable async nuance: in asynchronous mode, only the send counts as a request; collecting the response doesn't.
3. Undocumented. No public statement either way. Among the nine providers we checked, Serper is the one whose public site says nothing about failed-request billing (its pricing page isn't publicly accessible without an account — more on Serper's model in our Serper pricing breakdown). Undocumented doesn't mean unfavorable; it means you're relying on support tickets instead of terms.

What “success” actually means in the fine print

The word every policy hangs on is successful — and definitions differ in ways that show up on invoices:

• HTTP status. Traject Data draws the line at the protocol level: “you are never charged for unsuccessful requests. Only successful requests with a 200 status code incur charges.”
• The empty-200 edge case. A 200 with zero parsed results is not a failure by any published definition we found — the search executed; the engine genuinely had nothing (or the SERP contained only non-organic elements). Serpent API is unusual in documenting this explicitly in its public reference: credits are deducted before the search runs, any non-2xx response triggers an automatic refund, and empty 200s are billed because the search ran successfully. Most competitors' pages simply don't address the case.
• Async collection. On task-queue products, check which leg of the round trip is billable. Bright Data's FAQ says only the send is counted in async mode; DataForSEO's task model refunds “immediately” on failed tasks (see our DataForSEO pricing explainer for how its three queues behave).
• Retries. A retry is a new request everywhere we looked. If your client retries a failed call three times and the fourth succeeds, you pay for one success under a refund policy — but under a charge-anyway policy you'd have paid for four attempts. This is the multiplier that makes the policy matter.
• Cached results. One more definitional wrinkle from the quoted policies: SerpApi's wording exempts cached searches from its counter as well as errored ones — a repeat of a recent identical query may be served from cache and not billed there. No other provider in our table publishes an equivalent cache exemption, and cached responses are by definition not fresh, so treat this as a definitional detail to confirm rather than a discount to plan around. If freshness matters to your workload (rank tracking, news monitoring), ask how cache serving interacts with both billing and result recency.

Which SERP APIs charge for failed requests — the table

Every cell below is quoted from the provider's own public page, as seen July 17, 2026. Where nothing is published, we say so — “not documented” is itself the finding.

Policies change without notice — verify against the linked source before committing volume. Headline prices for the same nine vendors are in our cheapest SERP API comparison.

How to measure what failed requests actually cost you

The sticker price tells you the cost per attempt. What you care about is the cost per useful call — a call that returned data you kept. Pull three numbers from last month's logs and run this:

# Effective cost per useful call — paste your own numbers from last month's logs.
requests_sent   = 100_000
failed          = 4_200      # non-2xx responses (timeouts, upstream errors)
empty_200s      = 1_100      # 200 OK but zero parsed results
price_per_call  = 0.0006     # your provider's per-request price in dollars
failures_billed = False      # from the policy table above

billed_calls = requests_sent if failures_billed else requests_sent - failed
useful_calls = requests_sent - failed - empty_200s
spend = billed_calls * price_per_call

print(f"monthly spend:               ${spend:,.2f}")
print(f"effective cost per useful call: ${spend / useful_calls:.6f}")
print(f"premium over sticker price:  {(spend / useful_calls) / price_per_call - 1:.1%}")

Output with the numbers above (Python 3.12, run July 17, 2026):

monthly spend:               $57.48
effective cost per useful call: $0.000607
premium over sticker price:  1.2%

Flip failures_billed = True and the same workload costs $60.00 at $0.000634 per useful call — a 5.6% premium over sticker. At a 4% failure rate the policy is worth a few percent forever; during an upstream rough patch when failures spike to 15–20%, it's the difference between a flat bill and paying a fifth more for nothing. The empty-200 line is deliberately in the math too: no policy refunds those, so long-tail-heavy workloads carry a structurally higher effective cost whichever provider they choose — and only your own logs will show it.

Five questions to email a provider before you commit

The umbrella guide has the full ten-question checklist; these five are the failure-billing subset worth an actual email if the docs don't answer them:

1. Are non-2xx responses charged, and is that policy in your public terms (not just support folklore)?
2. Is a 200 response with zero results charged? What about a response where only non-organic elements parsed?
3. In async/task mode, which legs of the round trip are billable — submit, poll, collect?
4. If I retry a failed call, does each attempt bill independently once it succeeds?
5. Do refunds happen automatically, or do I have to file for them per incident?

A provider that answers all five in writing is telling you how it will behave when your bill is on the line. Silence on all five is an answer too. And because unused credit has its own fine print, check whether your credits expire while you're at it.

FAQ

Do SERP APIs charge for failed requests?

Mostly no — but only where it's written down. As of July 2026, SerpApi, SearchApi, DataForSEO, Traject Data, Zenserp, HasData, Bright Data and Serpent API all publish no-charge or auto-refund policies for unsuccessful calls. Serper's public site documents no policy.

Is a 200 response with zero results billed?

Almost always yes. The search executed and the engine returned nothing — the provider did the work. Serpent API documents the distinction explicitly (non-2xx auto-refunded, empty 200s billed); most competitors' pages don't address the case, so ask.

What counts as a successful SERP API request?

It varies: Traject Data draws the line at a 200 status; Bright Data bills only successful requests and doesn't count async collection calls; Serpent API auto-refunds anything non-2xx. The edge cases — empty results, partial parses, retries — are where definitions diverge.

How do I calculate my real cost per successful request?

Billed spend divided by useful calls (requests minus failures minus empties). At a typical 4% failure rate, a refund policy versus a charge-anyway policy is roughly a 4–6% premium on every real result — the snippet above computes it from three log numbers.

References & Further Reading

• SerpApi: Plans and Pricing
• SearchApi: Pricing
• DataForSEO: SERP API Pricing
• Bright Data: SERP API Pricing
• Traject Data: Error Handling & Reliability in SERP API Integration
• Zenserp: Pricing
• HasData: Pricing
• Serper.dev
• Serpent API: Live Pricing