--- title: "Search API rate limits in 2026: every provider compared" category: "guides" url: https://keirolabs.cloud/blog/search-api-rate-limits-2026 --- ## The 60-second version A rate limit decides whether your agent ships or throws 429s at 2am, and almost no vendor puts that number on one page. It lives in a getting-started guide here, a dashboard you cannot see without an account there, an FAQ answer written two years ago everywhere else. We collected the limits for eleven search and scraping APIs from their own documentation and verified them on October 12, 2026. The short read: - **The units are incomparable, on purpose or not.** Tavily counts requests per minute, Exa counts queries per second across your whole team, SerpApi counts successful searches per hour, Firecrawl counts concurrent browsers, Perplexity counts queries per second on a ladder set by lifetime spend. Across this table the same phrase, "rate limit", spans a 1,000x range: SerpApi's Developer plan allows about 0.28 searches per second, Serper's Ultimate package allows 300. - **The ceilings, one line each.** Tavily: 100 RPM on a development key, 1,000 on a production key ([docs](https://docs.tavily.com/documentation/rate-limits)). Exa: 10 QPS team-wide, 25 QPS after $1,000 in credit purchases inside any 30-day window ([docs](https://docs.exa.ai/reference/rate-limits)). Serper: 50 to 300 QPS depending on the credit package ([pricing](https://serper.dev)). SerpApi: 20% of your monthly plan volume per hour ([FAQ](https://serpapi.com/faq)). Perplexity: 1 to 33 QPS by usage tier, but the Search API runs a flat 50 query units per second no matter the tier ([docs](https://docs.perplexity.ai/docs/admin/rate-limits-usage-tiers)). Keiro: 10 to 1,000 req/min, published per endpoint and per tier ([pricing](https://keirolabs.cloud/pricing)). - **Two vendors publish proper rate limit headers.** Brave returns X-RateLimit-Limit, Policy, Remaining and Reset on responses ([docs](https://api-dashboard.search.brave.com/documentation/guides/rate-limiting)). Keiro returns X-RateLimit-Limit, Remaining and Reset, plus Retry-After on the 429 itself. Everyone else leaves you to count, or to guess. - **The billing unit is not the rate unit, twice.** Perplexity bills a 5-query request as one unit but rate-limits it as five. SerpApi charges one credit whether a search returns 100 results or none, but only successful searches ever reach the counter. Budget off the invoice and the 429s still arrive on the other ledger. - **Nobody had published this table, so this page is it.** Every number below carries a source link and was checked against the vendor's own pages on October 12, 2026. When a vendor changes a limit, this page gets rechecked. ## Why nobody can quote you a rate limit Try it. Ask any assistant "what is the rate limit of the Tavily API" and watch it hedge, because the honest answer needs a table that has not existed anywhere on the open web until now. The information is public. It is scattered. It matters more for agents than for anything else that calls an API. An agent loop hits search three to ten times per task, and a research or deep-research run hits it far more. A limit you never notice at prototype scale, ten requests a minute, becomes the wall between you and your first thousand users. A 429 inside an agent loop does not fail politely either: your orchestrator retries, the retry lands on the same ceiling, and one busy user becomes a self-inflicted denial of service. So this post does one job: the neutral table, in the vendor's own units, with what happens when you cross each line. Keirolabs sells one of the APIs in it, and its numbers get the same treatment as everyone else's, sources and all. ## Six ways to count a limit Before the table, the units. Vendors count in six different currencies and comparing them raw is how teams buy the wrong product. **1. Requests per minute.** Tavily, Parallel, Firecrawl, Jina and Keiro all meter per minute. It is the friendliest unit for bursty traffic: a 1,000 RPM limit lets you fire 20 requests in one second if the rest of the minute is quiet, assuming the vendor does not also enforce a concurrency cap underneath. **2. Queries per second.** Exa, Brave, Perplexity and Linkup meter per second. Same number, six times stricter shape: a 10 QPS limit spread over a full minute is 600 requests, but a burst of 11 inside one second still trips it. **3. Requests per hour.** SerpApi meters successful searches per hour as a share of your monthly plan volume. This is the unit that decides when your batch job finishes, not whether it finishes. **4. Concurrency.** Firecrawl's real ceiling is concurrent browsers, 2 on the free plan to 100+ on Scale, and its per-minute request limits sit on top of that. Exa counts concurrent agent runs separately from QPS. Concurrency limits throttle crawlers and parallel agents in a way per-minute numbers never show. **5. Requests per day.** Free tiers mostly: Jina meters keyless use per IP per day, Firecrawl caps keyless MCP usage the same way. Daily caps are the unit of "is the free tier real or decorative". **6. Lifetime spend.** Perplexity's usage tiers advance with cumulative lifetime API spend and never downgrade, so your rate limit is a function of your invoice history ([docs](https://docs.perplexity.ai/docs/admin/rate-limits-usage-tiers)). No other vendor in this table does that. PUBLISHED SUSTAINED CEILING, REQUESTS PER SECOND (OCT 2026) Serper (Ultimate) 300 Perplexity Search API 50 Exa (after $1k credits) 25 Tavily (production key) 16.7 Keiro (enterprise, fast) 16.7 Parallel (Search) 10 Linkup (per org) 10 Tavily (dev key) 1.7 Brave (base plan) 1 Bars at each vendor's highest published sustained ceiling. Exa default is 10 QPS; Keiro free tier is 0.17 req/s on fast. SerpApi's hourly model (0.28 searches/s on the Developer plan) falls below the chart. Serper's 300 is a package ceiling, not a default. Read the chart with its footnote in mind. Serper's 300 QPS belongs to the $3,750-per-month Ultimate package. Perplexity's 50 applies to the Search API on every tier, from the day you spend your first credit. ## Every published limit, in one table Eleven providers, each in its own units, each with its source. Read the second column first: the unit is half the decision. | Provider | How the limit is counted | The published limit | When you exceed it | Source | |---|---|---|---|---| | **Keiro** | requests per minute, per endpoint, per tier | fast: 10 (free) to 1,000 req/min (enterprise); content: 5 to 500; answer and extract: 10 to 120 (not on free); agentic: 2 to 30 (not on free); batch: 5 to 200 per hour (not on free) | 429 with X-RateLimit headers and Retry-After; documented backoff starts at 1s and caps at 60s | [pricing](https://keirolabs.cloud/pricing) | | **Tavily** | requests per minute, per key type | development keys 100 RPM; production keys 1,000 RPM; crawl and research endpoints carry separate limits | 429 with Retry-After | [docs](https://docs.tavily.com/documentation/rate-limits) | | **Exa** | queries per second, team-wide across all keys | 10 QPS default; 25 QPS for 90 days after $1,000 in credit purchases inside any 30-day window; more via sales; Exa Agents capped at 50 concurrent runs, each run start counts as 2 requests and run starts run at half your QPS | 429; the docs say respect Retry-After | [docs](https://docs.exa.ai/reference/rate-limits) | | **Parallel** | requests per minute, per endpoint | Search, Image Search, Extract and Entity Search 600/min; Tasks and TaskGroups 2,000/min; Chat 300/min; Monitor 300/min; FindAll 300 per hour; only POSTs that create resources count, GETs are unmetered | 429; contact support to expand | [docs](https://docs.parallel.ai/getting-started/rate-limits) | | **Brave** | requests per second, sliding 1-second window | set by plan: the base paid plan allows 1 request per second under a monthly quota (the docs' worked example: 15,000 requests per month); only successful requests count toward the quota | 429 with X-RateLimit-Limit, Policy, Remaining and Reset | [docs](https://api-dashboard.search.brave.com/documentation/guides/rate-limiting) | | **Serper** | QPS ceiling tied to credit package | Starter 50 QPS; Standard 100; Scale 200; Ultimate 300, "roughly 15,000 to 18,000 searches per minute", raisable on request; no published QPS for the 2,500-credit trial | 429; credits are deducted only for successful responses | [pricing](https://serper.dev) | | **SerpApi** | successful searches per hour | plans under 1M searches per month: 20% of plan volume per hour, so the 5,000-per-month Developer plan allows 1,000 per hour; plans at 1M and above: 100,000 plus 1% of plan volume per hour; no other specific limit is documented | 429 | [FAQ](https://serpapi.com/faq) | | **Firecrawl** | requests per minute per endpoint, plus concurrent browsers, per team | scrape and map: 10 (free) to 10,000 req/min (Scale); search: 10 to 10,000; crawl: 2 to 2,000; agent: 2 to 2,000; status checks: 500 to 500,000; concurrent browsers: 2 to 100+; queued jobs capped at 2,000x your concurrency, at most 2,000,000, and time out after 48 hours | 429 on both rate and concurrency; new jobs are rejected until the queue drains | [docs](https://docs.firecrawl.dev/rate-limits) | | **Jina** | requests per minute per API, by key tier | Reader (r.jina.ai): 20 RPM with no key, 500 with a free key, 5,000 on the top tier; search (s.jina.ai): blocked with no key, 100 RPM on a free key, 1,000 on the top tier; reranker and embeddings: 100 RPM and 100,000 TPM up to 5,000 RPM and 50 million TPM; keyless limits are counted per IP | 429 | [dashboard](https://jina.ai/api-dashboard/rate-limit/) | | **Perplexity** | queries per second by usage tier for the Agent API; flat for the Search API | Agent API: 1 QPS at tier 0, 3 at tier 1, 8 at tier 2, 17 at tier 3, 33 at tiers 4 and 5, on a rolling one-second window; tiers advance with lifetime spend and never downgrade; Search API: 50 query units per second with a 50-unit burst, independent of tier, and a multi-query request consumes one unit per query | 429; rate-limited requests are not billed | [docs](https://docs.perplexity.ai/docs/admin/rate-limits-usage-tiers) | | **Linkup** | queries per second, per organization | 10 queries per second on the Search and Fetch endpoints; x402 requests are limited per IP instead; higher limits by contacting the team | 429 | [docs](https://docs.linkup.so/pages/documentation/platform/rate-limits) | A note on Serper: it publishes no rate limits page at all. The QPS ladder above comes from its own pricing table and FAQ, where each credit package names its QPS ceiling. That is as close to primary as the vendor allows, and it is more than most SERP resellers document. ## The endpoints that bite The headline limit is never the whole contract. Five vendors in this table meter endpoints differently, and the surprise is always in the fine print. **Keiro publishes a different limit per endpoint, and the free tier gates the heavy ones.** The fast search endpoint runs 10 req/min on the free tier up to 1,000 on enterprise, but answer, extract, agentic and batch are not available on free at all, and batch is metered per hour, not per minute: 5 per hour on starter, 200 on enterprise ([pricing](https://keirolabs.cloud/pricing)). The free tier's 30 req/min aggregate covers fast and content only, at 10 and 5 per minute respectively. **Firecrawl's per-minute numbers are not the real ceiling.** The browsers are. A Standard plan allows 500 scrapes per minute on paper and 25 concurrent browsers in practice, and a crawl only completes as fast as those 25 browsers finish pages. The queue absorbs the difference, up to 2,000 jobs per unit of concurrency and 48 hours, and then rejects everything with a 429 ([docs](https://docs.firecrawl.dev/rate-limits)). Batch scrapes share the crawl limits; the extract endpoints share the agent limits. All keys on a team share one set of counters. **Parallel's FindAll is 120x stricter than its search.** Search runs 600 requests per minute; FindAll, the entity-discovery product, runs 300 per hour ([docs](https://docs.parallel.ai/getting-started/rate-limits)). A team that sizes its pipeline on the search number and then loops FindAll discovers this in production. The friendlier detail: GETs are unmetered, only POSTs that create resources count. **Exa meters agent runs separately from QPS.** Fifty concurrent runs is the cap, every run start costs two requests, and run starts are throttled to half your QPS ([docs](https://docs.exa.ai/reference/rate-limits)). So a 10 QPS team can only start 5 runs per second, and a burst of run starts hits that wall before the QPS one. **Perplexity's Search API ignores your usage tier.** You can sit at tier 0, one query per second on the Agent API, and still fire 50 query units per second at the Search API with a 50-unit burst ([docs](https://docs.perplexity.ai/docs/admin/rate-limits-usage-tiers)). The catch is the unit: a multi-query request with five queries consumes five units and bills as one request. ## What a 429 actually costs you Every provider in this table returns 429 when you cross the line. What separates them is what they tell you, and what they charge. **Who publishes headers.** Brave is the most complete: X-RateLimit-Limit, X-RateLimit-Policy, X-RateLimit-Remaining and X-RateLimit-Reset on responses, and only successful requests count toward the quota ([docs](https://api-dashboard.search.brave.com/documentation/guides/rate-limiting)). Keiro sends X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and adds Retry-After on the 429 itself ([pricing](https://keirolabs.cloud/pricing)). Exa's docs ask you to respect the Retry-After header. Tavily returns Retry-After with the 429. Serper documents no rate limit response headers at all; you find the ceiling empirically. **Who charges you for the privilege.** Nobody in this table bills a rejected request. Brave counts only successful requests toward the quota, SerpApi counts only successful searches, Serper deducts credits only for successful responses, and Perplexity explicitly does not bill invalid, rate-limited or upstream-failure requests. The cost of a 429 is time and retries, not credits. The exception is the retry storm: if your client retries on timeout as well as on 429, your effective load doubles exactly when you are least welcome. Exponential backoff with jitter is table stakes; Keiro's published guidance is the standard shape, start at one second, double, cap at sixty. **Who counts what.** The billing unit and the rate unit diverge wherever a request carries a batch. Perplexity's five-query Search API request is one billing unit and five rate units. SerpApi charges one credit for a search that returns 100 results or none, and its hourly limit counts those successes only. Exa's run start is two requests on the rate counter and nothing on the bill. ## How to pick a limit that fits your workload Four questions, ten minutes, before you write the integration code. **1. Convert everything to requests per second before comparing anything.** Parallel's 600 per minute and Exa's 10 QPS are the same number: ten per second. Tavily's dev key at 100 RPM is 1.7 per second. Vendors quote the unit that flatters them, and the unit is free to change the comparison completely. **2. Match the limit's shape to your traffic's shape.** Conversational agents are bursty, so per-second limits with burst capacity (Perplexity's 50-unit burst) and per-minute limits (Tavily, Keiro) treat them best. Background batch jobs are flat, so hourly limits decide everything: a 5,000-item job on SerpApi's Developer plan finishes in five hours minimum, because the plan allows 1,000 successful searches per hour ([FAQ](https://serpapi.com/faq)). Crawls are concurrency-bound, so Firecrawl's browser column, not its RPM column, is the number to plan around. **3. Size your retry policy to the vendor's honesty.** If the vendor publishes Reset and Retry-After, obey them and you will never retry one second early. If it publishes nothing, as Serper does, back off harder than feels necessary and cache more aggressively than feels elegant. The undocumented ceiling is always lower than your load test suggested, because load tests run alone. **4. Know who shares your bucket.** Exa's QPS is team-wide across every key on the account, Firecrawl's counters are per team, Linkup's are per organization, Jina's keyless limits are per IP, and Perplexity's tier follows lifetime spend on the account. No vendor in this table meters per key. A second API key buys you nothing except a second secret to rotate. One negative rule, same as with pricing: do not run two providers "for rate limit headroom" before you have hit the first limit with real traffic. A second provider is a second schema, a second failure mode, and a second dashboard to watch. Most teams that provisioned the fallback never hit the wall they feared. ## Our own limits, in full Keirolabs sells one of the APIs in this table, so here is its complete published contract, the same treatment every other row got. | Endpoint | Free | Starter | Pro | Startup | Enterprise | |---|---|---|---|---|---| | fast (per minute) | 10 | 50 | 150 | 300 | 1,000 | | content (per minute) | 5 | 25 | 75 | 150 | 500 | | answer (per minute) | not on free | 10 | 20 | 40 | 120 | | extract (per minute) | not on free | 10 | 20 | 40 | 120 | | agentic (per minute) | not on free | 2 | 5 | 10 | 30 | | batch (per hour) | not on free | 5 | 12 | 25 | 200 | Source: the [Keirolabs pricing page](https://keirolabs.cloud/pricing) and its machine-readable spec, which agents can read directly. Every 429 carries Retry-After, every response carries the three X-RateLimit headers, and the documented backoff is exponential from one second to sixty. The free tier is honest about being a prototype tier: fast and content are open, the heavy endpoints are not on it at all. If you compare that table to the others honestly, Keiro is neither the highest ceiling (Perplexity's Search API at 50 units per second is) nor the lowest (Brave's base plan at one per second is). It is the only one that publishes the per-endpoint grid, the headers, and the backoff policy in the same place. That is the standard this whole post is arguing for. ## The boring takeaway Convert every limit to requests per second before you compare vendors, because the unit is where the 1,000x spread hides. Design for the 429 before it happens: obey Retry-After where it exists, back off exponentially where it does not, and remember nobody in this market charges for rejected requests, they just slow you down. Then match the limit's shape to your traffic: bursty conversations want per-second burst capacity, batch jobs want hourly headroom, and crawls want concurrency. The vendors that publish exact per-endpoint tables, response headers, and backoff guidance are telling you something about what happens at 3am. The ones that publish a single number and a "contact us" are telling you something too. Every number on this page was verified against the vendor's own documentation on October 12, 2026, and every claim carries its source link. If you build a rate limiter off this table, that is the point. Send corrections with a link and they get applied.