APIs allow products to exchange information and trigger actions between different systems. Every time an application retrieves a customer profile, checks a payment, loads a map or sends a notification, it may be making a request to an API.
API providers use rate limits to control demand on shared infrastructure. The allowance may depend on the customer’s plan, the endpoint or the operation, so a product can reach a limit even while the provider’s service remains healthy.
A rate limit defines how many requests a user, application or system can make within a specific period. For example, an API might allow 100 requests per minute, 5,000 requests per hour or a certain number of requests per user.
When the limit is exceeded, the API may temporarily reject additional requests and return the HTTP status code 429 Too Many Requests.
The APIs for Product Managers book covers these constraints alongside the integration decisions that introduce them.
What are API rate limits?
An API rate limit is a rule that controls how frequently a client can send requests to an API. A delivery-status integration might share one allowance across every customer using the product. Refreshing each order on every page load can exhaust that allowance during a campaign, even when individual customers make few requests.
The scope of the allowance determines which users compete for capacity. A limit per account behaves differently from a limit shared by the whole application. Limits can be applied in different ways. An API provider might restrict requests:
- Per user or customer account.
- Per application or API key.
- Per IP address.
- Per endpoint.
- Per second, minute, hour or day.
Some providers also distinguish between sustained usage and short bursts of traffic. An application may be allowed to make several requests quickly, but not maintain that frequency indefinitely.
What does the 429 status code mean?
When an application makes more requests than the API permits, the service will often return a 429 Too Many Requests response. This does not necessarily mean that the API is unavailable or that something has permanently failed. It usually means that the application must slow down and wait before trying again.
The response may include a Retry-After header, expressed as a delay in seconds or an HTTP date. The client can use that value to schedule another attempt. Providers may also document quota headers and reset times; those conventions vary between APIs.
If the application ignores the response and continues making requests, it can create a retry loop that generates even more traffic and makes the original problem worse.
Why should Product Managers care about rate limits?
An exhausted quota changes what a product can show or complete while it waits for capacity. The fallback behaviour therefore needs a product decision. Imagine that your product uses an external API to show delivery information. If the application exceeds the provider’s request limit, users may see missing data, outdated information, loading errors or screens that appear to be broken.
The same issue can affect payment services, authentication systems, maps, messaging tools, analytics platforms and many other product capabilities. During discovery, Product and Engineering can establish the expected demand and the experience users will receive if requests are temporarily rejected:
- What limits does the API provider impose?
- Are the limits global or applied per user?
- What happens when we exceed them?
- What message will users see?
- Can we cache information instead of requesting it repeatedly?
- Will the expected traffic require a more expensive plan?
- How will we monitor rate-limit errors after release?
These questions are particularly important when launching a product in a new market, running a marketing campaign or introducing a feature that could create sudden traffic spikes.
How can a product manage API rate limits?
There are several ways technical teams can reduce the risk of exceeding an API’s limits. Retries need a waiting policy and a stopping point. Increasing delays, often with random variation, can spread renewed traffic over time. For actions that change data, the team must also check whether repeating a request can duplicate the operation.
Caching can reuse a stored response while it remains suitable for the feature. The team needs to agree how old delivery information, prices or account data may be before refreshing it.
Control request frequency: Requests can be distributed over time rather than sent all at once. This is useful for background processes, synchronisations and bulk operations. Use per-user limits: Products with many users can establish internal limits to prevent a single account from consuming too much capacity.
Monitor API usage: Dashboards and alerts can help teams detect when request volumes are approaching the provider’s limits. The right approach depends on the product, the importance of the data and how quickly that information changes.
Planning for quota constraints
A provider’s quota becomes a constraint on the product’s capacity. Forecasting demand means estimating requests per journey, shared usage and peak periods, as well as the number of users. Before launch, record the fallback experience, the retry policy and who will monitor quota consumption. A background sync may tolerate a delay that would leave an interactive checkout unusable.
The HTTP definitions are available in RFC 6585, section 4 and the Retry-After specification.
