Rate limit

Updated November 9, 2026

A rate limit is a cap on how many requests a client may send to a server in a defined time window. When the client exceeds that cap, the server refuses additional requests for a period, usually with HTTP 429 Too Many Requests and often a Retry-After header that says when to try again.

In short: An API rate limit caps how many requests a client can send in a time window, and exceeding it typically returns HTTP 429 with guidance such as a Retry-After header so the client can slow down and retry.

How API rate limits work

Rate limits protect shared infrastructure and keep one noisy client from starving everyone else. The server counts requests for a client identity inside a window. When the count crosses the published ceiling, further requests are rejected until the window allows more capacity.

RFC 6585 introduced the 429 Too Many Requests status for exactly this case 1. The response should explain the condition and may include a Retry-After header with how long to wait before a new request 1. MDN summarizes the same behavior for web and API clients 2.

Limits vary in shape.

Fixed window. N requests per second or per minute, then a hard stop until the window resets.
Sliding window or token bucket. Capacity refills continuously so short bursts are allowed without waiting for a clock boundary.
Concurrent cap. A maximum number of in-flight requests, separate from requests per second.
Tiered caps. Higher paying accounts receive higher ceilings.

RichAPI publishes a tiered per-second model tied to credits bought in a month. Sandbox gets 1 request per second, 5,000 credits get 10, 25,000 credits get 25, and 100,000 credits get 50 3. Short bursts of up to twice the steady limit are allowed 3. A request over the limit gets HTTP 429 with a Retry-After header 3.

Clients that ignore 429 responses retry in a tight loop and make the problem worse 1 2. The safe pattern is exponential backoff that honors Retry-After, plus a queue that spreads a bulk job across the allowed steady rate. Rate limits are separate from prepaid credit balances. Credits answer how much usage costs. Rate limits answer how fast usage may arrive. Teams running data enrichment or waterfall enrichment jobs need both numbers before they open a worker pool.

Agentic workflow loops that call tools without a concurrency cap are a common way to discover the limit the hard way. Bound the loop to the published steady rate before the first production run.

Document the limit next to the API key the same way credits are documented. A new hire who only sees the OpenAPI paths will open too many workers. A one-line note with the steady rps for the current bundle prevents that class of outage 3.

Multi-region or multi-process deployments need a shared rate limiter or a partitioned key strategy. Otherwise each process assumes it owns the full ceiling and the account trips 429s that look random from any single host 2.

What to design for before a bulk enrichment job

Four variables keep a bulk job inside the rate limit without wasting credits.

**Steady rate vs burst.** Size the worker to the published steady requests per second, not to the burst ceiling. Use the burst only for short spikes 3.

**Backoff that listens.** On 429, sleep for the Retry-After value when present 1 2. If the header is missing, use exponential backoff with jitter rather than a fixed one-second retry.

**Credit interaction.** Confirm whether a refused request spends credits. RichAPI states that hard failures never consume credits and that rate-limit checks refund automatically on failed requests 3. Still log every 429 so ops can see throttle events 2.

**Fan-out control.** Parallel workers multiply request rate. Cap concurrency so total requests per second across workers stay under the account limit.

**Shared accounts.** An MCP server and a REST worker that share one key also share one rate limit. Split jobs or raise the tier before running both at full speed 3.

Test the backoff path on purpose. Force a low artificial concurrency cap in staging, confirm the worker sleeps on 429, and only then raise concurrency toward the published steady rate 2 3.

Example of staying inside a per-second rate limit on a bulk job

A team must enrich five thousand LinkedIn profile URLs on a RichAPI Starter balance. Starter sits at 10 requests per second with bursts up to 20 3. Profile enrichment costs 1 credit per 2xx call 3.

text

Account tier     Starter (5,000 credits purchased)
Steady limit     10 requests per second
Burst ceiling    20 requests per second for short spikes
Worker design    8 concurrent requests, ~8 rps average
Expected runtime 5,000 / 8 seconds ≈ 10.4 minutes
On 429           sleep Retry-After, then resume at 8 rps
Credit forecast  up to 5,000 credits if every call returns 2xx

The worker never aims at the burst ceiling for the whole job. It stays near 8 rps so a second process can share the account without immediate 429s 3. Failed non-2xx calls are retried after backoff and do not spend credits 3.

That design treats the rate limit as a capacity plan for data enrichment, not as an error to crush with retries. The same pattern applies when an AI agent is the caller instead of a batch worker.

If a second team starts a parallel job the same afternoon, both agree to five requests per second each rather than discovering the shared ceiling through errors. That conversation is cheaper than a war room about flaky enrichment. The written rps budget becomes part of the runbook next to the credit forecast so the next operator inherits both constraints. Keep Retry-After logging on so postmortems show waits instead of guesses about flaky networks.

Rate limit vs API credits

Both constrain API usage. A rate limit caps speed. API credits cap how much billable work the balance can fund.

	Rate limit	API credits
What it answers	How fast may requests arrive?	How much billable usage remains?
Input	Client identity and a time window	Endpoint rates and a prepaid balance
Output	Allow or HTTP 429	Credits burned or a balance error
Cost driver	Concurrency and request shape	Billable calls and miss rules
Main risk	Retry storms that worsen throttling	Forecasting without the miss rule
Use it when	Designing workers and concurrency	Budgeting a campaign or pipeline

Read the reference →

Frequently asked questions

What is an API rate limit?

It is a cap on how many requests a client may send in a time window. Crossing it usually returns HTTP 429 Too Many Requests so the client can slow down instead of overwhelming the server 1 2.

What does HTTP 429 mean?

429 means the client has sent too many requests in a given amount of time 1. The response may include a Retry-After header that tells the client how long to wait before sending another request 1 2.

What are RichAPI's rate limits?

They scale with credits purchased. Sandbox allows 1 request per second, 5,000 credits allow 10, 25,000 allow 25, and 100,000 allow 50, with short bursts up to twice the steady limit and 429 plus Retry-After when exceeded 3.

Do rate-limited requests cost credits?

On RichAPI, hard failures never consume credits and rate-limit checks refund automatically on failed requests 3. Still handle HTTP 429 responses with backoff instead of tight retries that waste time and slots across the shared account limit 1 3.

The bottom line

A rate limit caps how fast a client may call an API. Exceeding it yields HTTP 429, often with Retry-After 1 2. Size bulk jobs to the published steady rate, honor backoff headers and keep throttle handling separate from credit budgeting. RichAPI publishes tiered rps limits tied to credits purchased 3 carefully.

Sources

RFC 6585: Additional HTTP Status Codes, IETF
429 Too Many Requests, MDN
RichAPI pricing, RichAPI