SERP API Rate Limits Compared: The Caps Nobody Advertises
SERP API rate limits are the ceiling most buyers discover only after they've paid: the monthly search volume on the pricing page tells you how much you can buy, but the rate limit decides how fast you're allowed to use it. As of July 2026, the documented limits range from 200 searches per hour on SerpApi's entry plan to 5,000 requests per minute on Value SERP's largest tier — a 1,500× spread that changes which provider can actually run your workload.
We compared the documented rate limits of seven SERP APIs — read from each provider's own pricing page or docs on July 17, 2026 — and worked the arithmetic that answers the question that actually matters: will your batch fit in your window? Where a provider publishes nothing, we say so, because an undocumented limit is itself a planning risk. (This piece covers provider policies; for the client-side engineering — concurrency control, backoff, resumable jobs — see our guide to running millions of SERP requests.)
The number on the pricing page is not your throughput
Every pricing page leads with searches per month. Almost none lead with searches per hour — and the hour is usually the binding constraint for real pipelines, which run as batches: a nightly rank check, an hourly brand sweep, a weekly content audit. Two plans with identical monthly volume can differ 10× in how fast they let you drain it.
There's a second wrinkle: rate limits and monthly quotas interact in odd ways. SerpApi's Big Data plan documents 30,000 searches per month at up to 6,000 per hour — meaning you could exhaust the entire month's quota in five hours flat. The hourly cap doesn't protect your quota; it just meters the burn. SearchApi inverts this: its documented rule is that you can spend at most 20% of your plan's credits in any hour, so whatever plan you buy, the whole month can never disappear in less than five hours. Same arithmetic, opposite philosophy.
Documented rate limits, provider by provider
Every cell below was read from the linked primary source on July 17, 2026. “Not documented” means we could not find a published number on the provider's public pricing page or docs — it does not mean no limit exists.
| Provider | Documented rate limit | Style | Source |
|---|---|---|---|
| SerpApi | Per-plan hourly throughput: 50/hr (free), 200/hr (Starter), 1,000/hr (Developer), 3,000/hr (Production), 6,000/hr (Big Data) | Absolute hourly cap | serpapi.com/pricing |
| SearchApi | “Up to 20% of your plan's credits each hour” (e.g. 20,000/hr on the 100k plan) | Percentage-of-plan hourly | searchapi.io/pricing |
| DataForSEO | 2,000 POST/GET API calls per minute total; each POST holds up to 100 tasks; raisable on request | Per-minute call ceiling | docs.dataforseo.com |
| Value SERP | Plan-tied real-time limits: 250/min (25k–50k plans) up to 5,000/min (largest tiers) | Per-minute, by plan | trajectdata.com |
| Zenserp | “We encourage not to exceed 400 concurrent connections” (standard plans); no per-minute/hour number | Concurrency guidance | zenserp.com/pricing |
| Serper | Not documented publicly (no rate-limit numbers on the public site; pricing itself sits behind signup) | — | serper.dev |
| Serpent API | Balance-scaled per-account windows: from 1 concurrent / 10 per min / 100 per hr / 500 per day (free) up to 100 concurrent / 500 per min / 5,000 per hr / 30,000 per day standard at $500+ balance — standard allocations that scale upward on request | Balance-scaled windows | apiserpent.com/docs |
Two structural observations. First, the biggest names are not the fastest lanes: SerpApi's largest published plan allows 6,000/hr, while Value SERP documents up to 5,000 per minute and DataForSEO accepts 2,000 calls a minute where a single call can carry 100 tasks. Second, silence is a real cost: when a provider publishes no numbers, you can't size a pipeline without trial-and-error against production — one of the hidden costs we cataloged in the fees pricing pages bury.
Four philosophies of limiting — and what each means for your batch
- Absolute hourly caps (SerpApi). Predictable, but they don't scale with your plan proportionally — check the cap on your tier, not the biggest one. A batch bigger than the cap must be spread across hours by design. Full tier math in our SerpApi pricing breakdown.
- Percent-of-plan hourly (SearchApi). Self-scaling: upgrade the plan and the hourly ceiling rises with it. The floor consequence: any full-plan workload takes at least five hours to run, whatever you pay.
- Per-minute ceilings (DataForSEO, Value SERP). The friendliest shape for bursts. Note DataForSEO's ceiling limits calls, and a POST can carry 100 tasks — submission is rarely your bottleneck there; queue turnaround is (see our DataForSEO queue guide).
- Concurrency rules (Zenserp) and balance-scaled windows (Serpent API). Concurrency limits constrain your worker pool rather than your rate; window systems (per-minute/hour/day) constrain both burst and sustained draw, and are the most explicit about what resets when.
The burn-down table: how fast can a whole month disappear?
A revealing way to compare limit philosophies: divide each plan's monthly quota by its documented maximum rate. The result is the minimum time in which the entire month's spend could be consumed — by a runaway cron job as easily as by a planned batch.
| Plan | Monthly quota | Documented max rate | Minimum time to burn the month |
|---|---|---|---|
| SerpApi Starter | 1,000 | 200/hr | 5 hours |
| SerpApi Big Data | 30,000 | 6,000/hr | 5 hours |
| SearchApi (any plan) | — | 20% of plan/hr | 5 hours, by construction |
| Value SERP 100k plan | 100,000 | 500/min | ~3.3 hours |
| Value SERP top tiers | up to 20M | up to 5,000/min | ~2.8 days |
| Serpent API ($500+, standard) | pay-as-you-go | 30,000/day standard | no month to burn — unused credit rolls forward |
The pattern: most subscription plans can be fully drained in a working afternoon, which is exactly why a stray retry loop can turn into a surprise renewal — SerpApi's overage model re-buys your plan early when you run out, a mechanic we unpack in the hidden-costs breakdown. Pay-as-you-go models don't have a month to burn; a runaway loop burns credit instead, which is why per-account rate windows plus never-expiring deposits are the combination we chose. Arithmetic ours, from the table above; quotas from each provider's pricing page, July 17, 2026.
The worked math: will your batch fit?
Three common workloads, run against the documented numbers above. The arithmetic is ours; every input is from the table.
1. “Check 15,000 keywords in a 2-hour nightly window”
- SerpApi: Production's cap is 3,000/hr → 15,000 needs 5 hours; Big Data's 6,000/hr → 2.5 hours. Neither fits a 2-hour window — and Production's entire monthly quota is one night's batch.
- SearchApi: on the 100k plan, 20%/hr = 20,000/hr → fits in ~45 minutes. On the 35k plan, 7,000/hr → ~2.1 hours; just misses.
- Value SERP: 100k plan documents 500/min → 15,000 in 30 minutes. Fits.
- DataForSEO: submission takes seconds (150 POSTs of 100 tasks); the question is queue turnaround, not rate limit.
- Serpent API: at the $500+ bracket, the standard 500/min allocation clears 15,000 in 30 minutes, within the 5,000/hr × 2 window. Fits on standard allocations.
2. “100,000 searches per day, sustained”
- SerpApi: no published plan reaches 100k/day — Big Data is 30,000 per month. This volume is enterprise/custom territory there.
- SearchApi: the Octo 5M plan (~166k/day of quota) documents 20%/hr = 1M/hr — rate is no constraint, spend is.
- Value SERP: the large tiers (up to 20M/mo, up to 5,000/min) handle it comfortably.
- Serpent API: the $500+ standard day allocation is 30,000 — 100k/day means asking for a custom allocation, which our docs describe as scaling upward on request. We'd rather say that plainly than let you discover it mid-migration.
3. “Burst 5,000 checks in 10 minutes” (algorithm-volatility spike)
- Requires a sustained 500/min. Documented fits: DataForSEO (2,000 calls/min), Value SERP 100k+ plans (500/min), Serpent API $500+ bracket (500/min standard). SerpApi's caps are hourly — 6,000/hr averages to 100/min, and minute-granularity behavior isn't documented. Zenserp and Serper: not determinable from public docs.
What actually happens when you hit the cap
The polite version is queueing; the common version is HTTP 429. Behavior worth knowing before you design retries:
- Serpent API documents its 429 contract publicly: the response carries a
Retry-Afterheader plusretryAfter,window(minute/hour/day) andlimitfields in the JSON body, and windows reset on fixed UTC boundaries. Your backoff can be exact instead of guessed. - DataForSEO documents the ceiling and says to contact them to raise it; batch submitters should throttle client-side below 2,000 calls/min.
- Most other providers don't document their 429 semantics. Treat any 429 as a signal of automated overuse of the window you're in: honor
Retry-Afterif present, back off exponentially if not — the full retry pattern is in our scale guide, and the queue-and-circuit-breaker architecture around it in SERP scraping at scale.
Planning headroom: three rules of thumb
- Size to 70–80% of the documented cap. Published figures are usually “up to” maximums, not guaranteed floors — our own docs say exactly that — and platform load can shave real throughput at any provider.
- Plan the window, not the month. Compute batch size ÷ usable window first; then confirm the monthly quota covers batch × frequency. Most sizing mistakes are window mistakes. Failed calls that consume window but deliver nothing compound this — check each provider's policy in our failed-request billing comparison.
- Price the limit, not just the call. A cheap per-1,000 rate behind a slow lane can cost more in engineering time than it saves. Model both with the SERP API cost calculator, then sanity-check against the cheapest SERP API breakdown.
Where Serpent API fits, honestly
Our limits are per-account, published in the docs, and scale with live credit balance across four brackets — from 1 concurrent / 10 per minute / 100 per hour / 500 per day on the free tier to 100 concurrent / 500 per minute / 5,000 per hour / 30,000 per day standard at a $500+ balance, with custom allocations available for larger workloads. The published numbers are standard starting allocations, not guaranteed floors, and creating extra API keys doesn't multiply them. If your workload looks like example 2 above, talk to us before you build — that conversation is free; a mis-sized pipeline isn't. Pricing for the calls themselves is on the SERP API page.
Plan a real workload on real numbers
Documented rate limits, documented 429 semantics with Retry-After, and per-call pricing from $0.60 down to $0.03 per 1,000 as your balance grows. Start free — 10 searches, no card, no minimum deposit.
Explore: SERP API · Pricing · Documentation
FAQ
What is a SERP API rate limit?
The ceiling on how fast you can call the API, separate from your monthly search volume. It comes as requests per hour (SerpApi), a percent of plan per hour (SearchApi), calls per minute (DataForSEO, Value SERP), concurrent connections (Zenserp), or balance-scaled windows (Serpent API). Exceeding it typically returns HTTP 429.
Why am I getting 429s while under my monthly quota?
Monthly quota and rate limit are different ceilings. Your burst exceeded the shorter window (minute or hour). Slow down, honor Retry-After when present, and spread the batch wider.
Which SERP API has the highest documented rate limit?
On July 2026 documentation: DataForSEO's 2,000 calls/min (up to 100 tasks per POST) and Value SERP's 5,000/min top tiers lead; SerpApi's largest published plan is 6,000/hour. Several providers publish nothing at all.
Do rate-limit windows reset at midnight?
Mostly undocumented elsewhere. Serpent API documents fixed UTC resets (top of minute/hour; 00:00 UTC daily). When unspecified, assume rolling windows and keep headroom.
Can rate limits be raised?
Usually on request: DataForSEO says contact them; SerpApi sells custom enterprise plans; Serpent API offers custom per-account allocations above the standard ones.



