What is API Rate Limits?
API rate limits are rules that control how much work a caller may ask an application programming interface to perform over time. A service might allow a certain number of requests per second, charge different operations against a shared points budget, or restrict how many requests can be active together. The allowance belongs to a defined scope, such as an account, application, endpoint or IP address. It does not describe your broadband download speed, and a faster connection does not automatically increase it.
If the underlying concept is unfamiliar, an application programming interface is the structured interface through which software asks another system for data or actions. Rate limits govern that interaction. A home dashboard fetching energy readings, a backup script listing cloud files and a business application creating orders can all encounter them, even when their internet connection works normally.
Why APIs limit requests
An API request can consume database queries, processor time, memory or access to another service. A small response does not necessarily mean cheap work. Repeated searches or writes may cost more than downloading a larger cached object.
Limits help a provider share resources, contain faulty integrations, reduce abuse and control demand. They also establish predictable operating boundaries for customers. A limit may protect one expensive operation while another protects the account as a whole.
API rate limits are an application of rate limiting. The important practical question is which resource and identity the policy counts. Network traffic shaping measures a different resource, commonly bytes or bits over time, so its settings cannot be substituted for an API allowance.
What does the allowance actually count?
Before planning a workload, establish the unit, scope, time rule and treatment of unsuccessful attempts. The headline number alone is insufficient.
Policy | What is counted | What the client must control |
|---|---|---|
Request rate | Calls admitted during an interval or against a refill rate | How quickly new attempts start |
Weighted work budget | Points, tokens or other documented units | The combined cost of operations |
Concurrency limit | Requests currently in progress | How many operations remain active |
Longer-period quota | Usage over a day, billing period or other allocation | Total demand and replenishment rules |
Endpoint or resource limit | Activity against a particular operation or object | The affected subset of work |
An AI API may count input or output tokens as well as requests. A search API may assign points to queries. A monthly allocation may coexist with a much tighter short-term limit. These are separate constraints: unused monthly capacity does not prove that a burst is allowed.
One request need not mean one unit
Consider an illustrative budget of 12 units. Reading one record costs one unit, while a complex query costs four. Eight reads plus one query use 8 + 4 = 12 units, although only nine HTTP calls were made. Three complex queries also use the entire budget.
This is an invented teaching example, not a provider tariff. The lesson is to schedule in the documented unit. A request counter cannot accurately enforce a weighted allowance unless it incorporates each operation's cost. Where cost is only known after execution, the client may need a conservative reservation followed by reconciliation.
Several callers can share one budget
Scope determines who competes for the allowance. Four processes using credentials associated with one account may consume a shared allocation. Conversely, one provider may maintain distinct allowances for separate resource families.
Account or tenant: work from several applications may compete.
User: different tokens can still act on the same identity.
Application or installation: background workers may share the same installation budget.
Endpoint or object: a busy operation can be restricted while unrelated calls continue.
Source IP: callers sharing an outward-facing address can affect one another.
Changing an API key does not establish a new allowance. Determine the actual ownership rules before diagnosing an unexpectedly low remaining count. Credentials must retain appropriate permissions; rotating identities to evade a policy is not a reliable integration design.
Where the decision happens
A request can encounter an edge service, API gateway, account policy and application-specific limiter before reaching the operation itself. Conceptually, the enforcing component identifies the caller, determines applicable policies, checks usage and either admits, rejects or delays the work.
The infographic shows a typical rejection using HTTP 429. It is an explanatory path, not a promise that every provider uses the same status or enforcement location. An upstream gateway and the application can enforce different budgets, and a response may identify only the constraint encountered first.
Distributed systems also need coordinated accounting. If each of four servers independently grants the complete account allowance, a client reaching all four can consume more than the intended total. Shared state, partitioned budgets or another coordination scheme addresses this. An atomic check and update prevents two simultaneous requests from spending the same final unit.
The coordination itself has a cost and failure policy. An API designer must decide what happens when the accounting service is unavailable: allowing requests risks overload, while denying them risks unnecessary interruption. Enforcement targets and regional behaviour therefore need documenting rather than assuming perfect global precision.
How API rate limits handle bursts
Two services advertising a similar requests-per-minute allowance can behave differently because they use different time models.
Model | Mechanism | Important consequence |
|---|---|---|
Fixed window | Count within successive non-overlapping intervals | Calls either side of a boundary can form a large burst |
Sliding window log | Retain timestamps within the latest interval | The interval moves with each request |
Sliding window counter | Estimate recent usage from overlapping counters | Less storage, with approximation depending on implementation |
Token bucket | Spend stored tokens replenished at a defined rate | Bucket capacity permits bursts; refill controls sustained admission |
Leaky bucket | Drain accumulated work at a controlled rate | Shaping delays work; policing can reject overflow |
These are conceptual models, not a method for identifying an undocumented provider implementation. AWS API Gateway, for example, documents token-bucket throttling and describes its configured limits as best-effort targets. Do not turn a published target into a universal guarantee of exact admissions.
Techie Broadband model: six requests per minute
We ran a local synthetic Python model with exact rational arithmetic. It sends six requests at 59.9 seconds and another six at 60.1 seconds. All requests cost one unit; there is no earlier traffic, processing delay or concurrency limit. Fixed windows begin at time zero and last 60 seconds. The sliding model counts accepted requests in the preceding 60 seconds. The token bucket starts full, holds six tokens and refills at 6/60 = 0.1 token per second.
Model | Accepted at 59.9 seconds | Accepted at 60.1 seconds | Total accepted |
|---|---|---|---|
Fixed 60-second windows | 6 | 6 | 12 |
Exact sliding window log | 6 | 0 | 6 |
Six-token bucket, refill 0.1 per second | 6 | 0 | 6 |
The fixed-window counter resets between the bursts, admitting 12 requests across 0.2 seconds without exceeding six in either individual window. The sliding model still sees the earlier six. The bucket has replenished only 0.2 × 0.1 = 0.02 token, which is insufficient for another one-unit request.
This is original explanatory analysis, not testing of a commercial API. It shows why evenly dividing a per-minute number into requests per second does not reveal burst permission or reset behaviour. A token bucket also does not imply a fresh full allowance at every minute boundary.
What HTTP 429 and retry headers mean
The IETF's RFC 6585 definition of HTTP 429 describes too many requests within a period of time. Its April 2012 specification allows a Retry-After header but does not require one or define the counting algorithm. It also prohibits caches from storing a 429 response. Servers are not required to emit 429 for every overload condition.
Read the status, response body and headers together. Do not treat an absent header as zero waiting time, a guarantee of immediate replenishment or proof that limiting did not occur.
Response information | Useful interpretation | Common mistake |
|---|---|---|
Retry-After | Waiting guidance, expressed as seconds or an HTTP date | Treating every value as a timestamp |
Remaining allowance | Snapshot for the indicated policy or resource | Assuming it covers every limit |
Reset time | Provider-defined replenishment information | Assuming every reset field uses the same units |
Limit reason or error code | Identifies the affected constraint | Diagnosing solely from the HTTP status |
Request identifier | Helps correlate a particular attempt | Logging an API secret instead |
HTTP Semantics, RFC 9110 section 10.2.3, defines Retry-After as a non-negative integer number of seconds or an HTTP date. The infographic's Retry-After: 60 is an example of a 60-second delay, not a standard allowance. A dated value needs correct clock handling. Provider-specific reset headers require their own documented parsing.
Provider examples that prevent misdiagnosis
GitHub's REST API rate-limit documentation distinguishes primary and secondary limits. Rate-limited responses can be 403 or 429. Its primary-budget reset header uses UTC epoch seconds; secondary limiting can occur while a primary budget remains. Follow the stated response and provider instructions rather than repeatedly spending the apparent remaining balance.
Stripe's rate-limit documentation separates rate and concurrency limits and exposes a Stripe-Rate-Limited-Reason header. Its 429 responses without that header can instead indicate an object lock timeout. Reducing simultaneous mutations on the same object addresses a different problem from spreading a general account request rate.
A 403 can also represent an authorisation failure, and a 503 is not by itself proof of an account quota. Waiting will not repair incorrect credentials, missing permissions or an invalid request. Conversely, a timeout does not establish whether an operation was processed.
Pace the entire workload, including retries
The client needs a control point that matches the provider's scope. A shared account budget usually needs aggregate scheduling across the processes consuming it, not an independent sleep in each worker.
For an illustrative allowance of five starts per second, four workers each starting two requests per second produce 4 × 2 = 8 starts per second. The application exceeds the sustainable rate by three. If every job is queued and none is discarded, sustained arrivals add 3 × 60 = 180 pending jobs per minute. A queue moves the pressure into waiting time; it does not create extra capacity.
Separate interactive work from bulk processing so a migration does not consume every available slot. Set queue capacity, maximum job age and an explicit policy for work that cannot finish before its deadline. Repeatedly fetching a state that has already been superseded can be less useful than discarding the obsolete poll.
Concurrency is a separate control
A concurrency cap limits active requests rather than starts per second. In an ideal fully occupied system, four slots with an average slot occupancy of 0.2 seconds support approximately 4/0.2 = 20 completions per second. At one second per request, the same slots support approximately four. This theoretical calculation assumes continuous demand, stable average duration and no other constraints.
If an independent rate limit allows only five starts per second, the first case remains constrained by that rate policy. The second may be constrained by occupancy. Reducing latency can shorten client-held occupancy, but whether it affects the server's concurrency counter depends on where and when that counter starts and ends.
Retry without making overload worse
Use the provider's documented minimum waiting instruction. Where it requires exponential backoff, increase waits across repeated failures and cap attempts and elapsed time. Random jitter helps prevent many clients returning together. If a minimum wait is specified, any jitter must preserve it rather than schedule an earlier attempt.
Retries must return through the same scheduler as fresh work and count towards its allowance. Inspect SDK behaviour before adding another retry loop. If the application makes three attempts and its HTTP layer independently makes three for each, one logical operation can cause 3 × 3 = 9 downstream attempts. That is a worst-case illustration when all attempts run, not an observation of any particular SDK.
For writes, verify retry safety separately. A lost response can follow a committed action. Use the API's documented idempotency mechanism where available, preserve the same operation identity across its permitted retry scope and reconcile uncertain outcomes. An idempotency key's lifetime and conflict behaviour are provider-specific. Do not assume a repeated POST is safe just because the first attempt timed out.
Reduce demand before buying more allowance
Cache reusable data where freshness, access control and provider rules permit it.
Combine identical in-flight reads so several callers can share one result.
Filter and paginate deliberately rather than repeatedly downloading an entire dataset.
Use documented batch operations where useful, while checking their weighted cost.
Spread scheduled jobs and coordinate workers against the shared policy.
Remove duplicate retry layers and unnecessary status polling.
Conditional requests can save transfer volume without universally saving quota. GitHub's best-practice guidance gives authenticated qualifying 304 Not Modified responses special primary-budget treatment, but another API may count the request regardless. Confirm both the caching semantics and the accounting rules.
Where supported, webhooks can replace frequent requests asking whether anything changed. They introduce delivery, authentication and duplicate-handling requirements of their own. Follow-up API calls and reconciliation still consume their relevant budgets, so event delivery is not an unlimited substitute for all API access.
A higher allowance may be appropriate when useful, optimised demand genuinely exceeds capacity. Check which policy can be increased, whether burst and concurrency limits change, and whether the effective scope matches your integration. A larger monthly package can leave a short-term endpoint constraint untouched.
What this means for UK broadband and home labs
On an FTTP connection, a small API request can reach a remote service quickly while still being rejected by application policy. Increasing a line from hundreds of megabits to gigabit capacity does not alter an account's request budget. A faster transfer can even let an unpaced script generate attempts sooner.
Broadband conditions still matter. Slow uploads, packet loss, busy WiFi or long round trips can delay calls or increase timeouts. That can raise retry demand or keep client slots occupied longer. The diagnosis should distinguish these effects from a policy response rather than attribute every slow integration to the ISP.
Source-IP limits need special care where household devices, a business gateway, a VPN exit or CGNAT share an outward-facing address. GitHub's unauthenticated REST requests are one documented example of originating-IP accounting. Shared-address consequences are conditional on the API using that identity; authenticated account limits do not automatically become per-IP limits because CGNAT is present.
Avoid exposing secret API keys in browser code, screenshots or logs. Use suitable server-side handling and least-privilege access for private integrations. Rate limiting helps control demand but is not authentication, access control or complete protection against denial-of-service attacks.
Troubleshoot a rate-limited integration
Record one failed attempt: time, method, endpoint, status, error code, relevant headers and request identifier. Redact secrets and sensitive payloads.
Identify the enforced scope and unit from current provider documentation. Confirm production and test environments separately.
Read the retry instruction and any reason field. Establish whether the failure concerns rate, weighted cost, active requests, an object lock or authorisation.
Inventory every worker, scheduled job and SDK retry loop using that scope. Compare aggregate attempts with successful logical operations.
Pause bulk jobs, reduce concurrency and resume through a shared paced queue after the required wait. Observe which change removes the problem.
Reduce avoidable work, bound retries and inspect queue age. A growing backlog means demand still exceeds useful processing capacity.
Investigate the network separately if failures are timeouts, connection errors or unusually long calls. Compare a wired connection and a small known-good request without deliberately flooding the service.
Escalate with redacted response evidence and workload timings if the documented policy does not explain the result. Request a suitable allowance increase where justified.
Do not repeatedly send requests simply to discover a live threshold. Use local mocks and synthetic models for burst tests; production probing can consume shared allowance and disrupt unrelated work. A successful speed test proves neither API capacity nor correct retry behaviour.
Measurements that make the next incident easier
Record attempt rate and successful logical operations separately, grouped by the actual scope and endpoint. Useful signals include active requests, weighted usage, response reasons, remaining-budget snapshots, retry attempts, queue depth and oldest-job age. Check short intervals: a calm minute average can conceal an intense one-second burst.
Track completion before deadline, duplicate side effects and abandoned work as well as HTTP success. An integration that eventually succeeds after repeated retries may still deliver stale data or consume excessive capacity. Treat response headers as observations, not a reservation of capacity against other concurrent callers.
The practical takeaway
The useful question is not simply how many requests are allowed. Ask what is counted, who shares the allowance, how bursts are treated and what the response requires next. Then coordinate fresh work and retries within those rules. Broadband improvements can address network delay, while application pacing and demand reduction address an API budget.
For related networking definitions, the Techie Broadband terminology glossary provides the wider reference context.
API rate limits questions answered
What are API rate limits?
API rate limits control how much work a caller can request over time. The policy defines the counted unit, the caller or resource scope and the time model. Request-rate, weighted-cost and concurrency restrictions can apply together.
Does faster broadband increase an API rate limit?
Faster broadband can reduce transfer time, but it does not automatically increase the allowance assigned by an API provider. It may help network delay while leaving account, endpoint and concurrency policies unchanged.
Does HTTP 429 always mean the same problem?
HTTP 429 normally indicates too many requests, but provider-specific error details matter. Stripe, for example, can return 429 for an object lock timeout. Other providers can use 403 for rate limiting. Read the body, headers and current documentation together.
When does an API rate limit reset?
There is no universal reset schedule. Fixed windows, sliding windows, token refill and longer-period quotas behave differently. Follow the provider's documented time rule and response headers rather than assuming the allowance returns at the start of every minute.
Should I retry immediately after reaching a limit?
Follow the provider's waiting instruction and retry policy. Use bounded attempts, coordinate retries with other work and preserve any required minimum delay. Check write safety and idempotency before repeating an operation with side effects.
Can webhooks eliminate API rate limits?
Webhooks can reduce polling when the service supports suitable events. They do not remove limits on subsequent API calls, reconciliation or other operations, and the receiving application still needs safe delivery and duplicate handling.
