Brave Search API

More Search API pages

API glossary

Rate limiting

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Rate limiting is the practice of capping how many requests a client (often an app on a computer or mobile device) can make to a service within a set period of time. When a client exceeds the limit, the service rejects or delays further requests (usually returning an HTTP 429 Too Many Requests response) until the window resets. Rate limiting protects a service from overload, ensures fair access among users, and enforces the usage tiers that many APIs sell.

In short: rate limiting caps how many requests you can make in a given time window, so no single client can overwhelm a service or exceed the plan it is paying for.

How rate limiting works

A service tracks each client’s usage against a defined allowance:

  1. Define a limit: The service sets a quota, such as requests per second, per minute, or per month, often tied to an API key or IP address.
  2. Count requests: Each incoming request is counted against the quota using an algorithm such as a fixed window (reset at set intervals), sliding window (rolling count over the last N seconds), or token bucket (a running allowance that refills at a steady rate).
  3. Allow or reject: If the client is under the limit the request proceeds; if the client is over its limit, the service returns a 429 response instead of processing it.
  4. Signal to the client: Response headers from the service will communicate this state. For example, a response header like “RateLimit-Remaining” can show how much quota is left, while “Retry-After” tells the client how long to wait before trying again.
  5. Reset: When the time window elapses, the quota refills and requests are accepted once more.

The defining idea is that rate limiting is a contract, not a failure: a 429 is the service asking a client to slow down, not a sign that something is broken.

Rate limiting vs. throttling and quotas

  • Rate limiting and throttling are often used interchangeably, though they can be distinguished: rate limiting sets a hard cap and rejects requests over the threshold with a 429, while throttling slows or queues excess requests rather than refusing them outright.
  • A rate limit is usually a short-window cap, per second or minute; a quota is typically a larger allowance over a longer period, per day or month. APIs often enforce both at once.
  • A 429 response means the client exceeded its limit and should pause and retry according to Retry-After (when present) or a backoff policy; a 503 response means the server is unavailable (whether due to overload, maintenance, or another server-side issue) rather than a client quota problem.

Where rate limiting matters

  • Building on any API: Well-behaved clients respect Retry-After, apply exponential backoff with jitter (waiting progressively longer between retries, with added randomness to avoid multiple clients retrying simultaneously), and watch RateLimit-Remaining to slow down before hitting the cap.
  • High-volume and agentic workloads: An agentic search system that fires many calls in a loop can hit limits quickly, so request queuing and backoff are essential.
  • Crawling: When a site returns repeated 429s, search crawlers reduce their crawl budget for it until normal responses resume.
  • Search APIs: A search API publishes rate limits per plan, usually as requests per second and per month, so choosing a tier means matching those limits to your expected query volume; graceful handling of 429s keeps an answer pipeline reliable when traffic spikes, and higher, more predictable limits primarily affect throughput and client-side queueing, with latency impacts that are typically indirect and workload-dependent.

Rate limiting is part of the contract between a client and any API: designing around it, rather than against it, is what keeps an integration stable as it grows.

Throughput, latency, HTTP 429, Retry-After, exponential backoff, quota, API key, crawl budget, search API.