API Rate Limits: How They Work and How to Handle Them

An API rate limit is a cap on how many requests a client can send to an API in a set window of time, such as 80 per minute or 5,000 per hour. When you go over it, the API rejects the extra requests, usually with an HTTP 429 status, until the window resets. If you are building an app, you handle limits by reading the response headers, slowing down, retrying with backoff and cutting unneeded calls. If you run an API, you set limits from load testing and tell clients clearly when they hit them.

This guide covers both sides: what limits are, why they exist, how to fix the “rate limit exceeded” error, and how to choose limits for your own API.

TL;DR

• A rate limit caps requests per time window. Providers use it to prevent overload, keep usage fair, improve security and control costs.
• When you exceed a limit, expect HTTP 429. Read the retry guidance in the response, wait, then retry with exponential backoff if no guidance is given.
• Reduce your call volume first: cache responses, batch requests, use webhooks instead of polling and queue background work.
• If you run an API, set limits from load tests, return clear overload signals, and review the numbers regularly.
• Retries must be safe. Use idempotency keys so a retried request never repeats a payment, order or email.

Table of Contents

• What API rate limits are and how they work
• Why APIs have rate limits
• How rate limit algorithms differ
• How to fix “API rate limit exceeded”
• How to rate limit an API to 10 requests per minute
• Best practices for running an API with rate limits
• A quick planning checklist for your app
• Our perspective
• Get help building an app that handles limits well
• FAQ
• Sources

What API rate limits are and how they work

Rate limiting, also called request throttling, controls how many requests a client can make within a specified time window, as the Postman guide to API rate limiting describes it. In cloud APIs, Microsoft’s explanation of rate limiting frames it as a cap on both the speed and the volume of API calls.

The “client” can be a user, an API key, an app, an IP address or a whole organization. Providers choose which one to count. That choice matters for you. If limits apply per API key, one busy background job can use up the allowance your customer-facing screens need.

Here are some real examples of how different providers set limits:

• GitHub allows in general no more than 80 content-generating requests per minute and no more than 500 per hour, according to its REST API rate limit documentation. It also separates primary limits from secondary limits.
• Datadog sets its event submission limit at 250,000 events per minute per organization, per its API rate limits page. Other endpoints have their own limits.
• Shopify limits pagination of arrays of objects to 25,000 objects, because deep pagination is resource intensive, as its API limits documentation explains.
• OpenAI organizes its limits by usage tiers, described in its rate limits guide.

The takeaway: there is no universal number. Every API publishes its own limits, and they can change, so read the provider’s current documentation before you design around them.

The headers that tell you where you stand

Many APIs return headers that report your status. According to Microsoft, APIs may return RateLimit-... or X-RateLimit-... headers, where RateLimit-Remaining shows how many requests are left and RateLimit-Reset shows when the limit resets (see the Microsoft Learn explainer). Log these values in development. They tell you how close your app runs to the ceiling before users ever see an error.

Why APIs have rate limits

According to Microsoft, APIs impose rate limits to prevent overload, ensure fair usage, increase security, manage costs and maintain quality of service. Each of those is a practical reason:

• Overload protection. A sudden spike, from a bug, a bot or a viral moment, can take down a service for everyone.
• Fair usage. One heavy customer should not starve the others.
• Security. Limits slow down credential stuffing, scraping and brute-force attempts.
• Cost control. Every request uses compute, bandwidth and often paid downstream services.
• Quality of service. Predictable load means predictable response times.

An academic pattern collection on API rate limit adoption adds that the pattern protects API resources and supports fair allocation, and that its details may be tied to subscription levels or service level agreements (SLAs). In plain terms: on many APIs, the plan you pay for decides your limit. Check what your plan includes before you promise a customer a feature that depends on high call volume.

How rate limit algorithms differ

If you only consume APIs, you do not need to implement these. Knowing them still helps you predict how a provider will behave. If you run an API, you have to choose one.

These descriptions follow the Postman overview of limiting algorithms. Stripe’s engineering team explains the token bucket in more depth in Scaling your API with rate limiters: tokens are added at a fixed rate, which allows short bursts while enforcing an average rate.

For most business apps, the token bucket is the friendliest model for the client. You can send a quick burst when a user clicks “sync,” then settle into a steady pace.

How to fix “API rate limit exceeded”

When you see this error, work through these steps in order.

1. Read the response, not just the status code

The Azure Well-Architected guidance on designing throttling says that for user-limit breaches an API should return 429 with a Retry-After header, and that clients should honor that guidance. For service-level constraints, such as the service itself being overloaded, it recommends HTTP 503. So a 429 means you sent too much. A 503 means the provider is struggling. Handle them a little differently: with 429 you slow yourself down, with 503 you back off and wait for the service to recover.

2. Wait for the time the API tells you

If Retry-After says 30 seconds, wait 30 seconds. Do not guess a shorter time. Retrying early usually resets nothing and can extend the penalty on some APIs.

3. Use exponential backoff when no retry hint is given

The same Azure guidance says clients should use exponential backoff if a 429 comes with no retry headers. The pattern is simple: wait 1 second, then 2, then 4, then 8, up to a maximum, and stop after a set number of attempts. Add a small random delay (jitter) so many clients do not all retry at the same instant. Here is the logic in plain steps:

1. Send the request.
2. If it returns 429 and has a Retry-After value, wait that long and retry.
3. If there is no value, wait for a base delay multiplied by 2 for each attempt, plus a random amount.
4. After a maximum number of attempts, stop and show the user a clear message or put the job in a failed queue.

4. Make retries safe

Backoff is easy for a read request. It is riskier for a request that changes data. If a “create order” call times out and you send it again, you may create two orders. One system design reference notes that retries that mutate data need to consider the consequences of duplicate action (Design a Distributed Scalable API Rate Limiter). The standard fix is an idempotency key, a unique ID that lets the server recognize a repeat and return the first result. This walkthrough of idempotent API design, keys and versioning shows how to avoid duplicate actions and retry storms when requests are throttled.

5. Cut the number of calls you make

Backoff treats the symptom. Fewer calls treat the cause. These changes usually have the biggest effect:

• Cache. If data changes rarely, store it for minutes or hours instead of fetching it on every page view.
• Batch. Many APIs let you send or fetch multiple records in one call.
• Use webhooks instead of polling. Asking “anything new?” every few seconds burns your allowance on empty answers.
• Request only what you need. Use field selection and filters, and avoid deep pagination on large collections.
• Queue background work. Put non-urgent calls in a queue and process them at a steady pace below the limit.
• Spread jobs out. Do not run every nightly sync at midnight on the dot.

6. Ask for a higher limit or move up a plan

If your usage is legitimate and steady, you may simply need more capacity. GitHub’s documentation has a section on getting a higher rate limit, and many providers tie higher limits to paid tiers or enterprise agreements. Check the provider’s pricing and documentation, and contact their support with your expected volume.

How to rate limit an API to 10 requests per minute

This is a common starting question, and the answer is that the number is the easy part. A simple approach for a small API:

1. Pick the identity to count: API key, user ID or IP address.
2. Choose the algorithm. A token bucket with a capacity of 10 and a refill of one token every 6 seconds gives you 10 per minute on average, with bursts up to 10.
3. Store counters in a fast shared store such as Redis if you run more than one server, so every server sees the same count.
4. Return 429 with a Retry-After header and a clear message when the bucket is empty.
5. Return the remaining count in headers on every response, so clients can pace themselves.

Most API gateways and frameworks offer this as a built-in setting. Use that before you write your own.

Best practices for running an API with rate limits

If you publish an API, whether for customers, partners or your own mobile app, these practices come from the major cloud architecture guides.

Set limits from testing, not from guesses

The AWS Well-Architected guidance on throttling requests says teams should establish limits through load testing, document the tested limits, and not exceed validated levels unless provisioned resources meet or exceed the test scenarios. A limit of 1,000 requests per minute that your database cannot actually serve is not protection.

Define dimensions and signal overload clearly

Azure’s guidance lists defining throttling limits and their dimensions (per user, per key, per endpoint), returning clear overload signals, monitoring saturation, and reviewing and validating limits periodically. It also advises validating limits through controlled testing and low-limit exercises, where you deliberately set a limit low to confirm that clients and alerts behave correctly.

Include retry guidance only when retrying is safe and intended. If a request is failing for a reason a retry will not fix, say so.

Buffer and smooth traffic

AWS suggests token bucket throttling and using services like API Gateway, SQS or Kinesis to buffer requests and smooth request rates. It also notes that when you use Amazon SQS queues with AWS Lambda, setting maximum concurrency prevents the consumer from exhausting resources meant for other functions.

Keep an escape valve

Stripe’s engineers recommend that if a rate limiter causes issues, you have feature flags and what they call human escape valves, so you can restore service quality immediately. A limiter that wrongly blocks your biggest customer is an outage. Build in a way to loosen or switch it off fast.

Document everything

Publish your limits, the headers you return, the error format and your recommended retry behavior. Developers should never have to discover your limits by hitting them.

A quick planning checklist for your app

Before you launch a product that depends on third-party APIs, walk through this list:

• List every external API your app calls and note each limit, its window and how it is counted.
• Estimate peak calls per user action, then multiply by peak concurrent users.
• Decide what the user sees when a call is throttled: a spinner, a queued status or a friendly retry message.
• Put non-urgent calls on a queue.
• Log rate limit headers and alert when remaining capacity drops below a threshold you choose.
• Check whether your plan with each provider matches your expected growth.

This is the kind of planning that is cheap on day one and costly after launch. It is also where no-code and low-code apps most often get surprised. Platform workflows can fire many API calls without making that obvious, so a screen that looks simple may use a lot of your allowance.

Our perspective

Most rate limit problems we see are not caused by a provider being strict. They come from an app that was designed without thinking about calls at all. A dashboard that refreshes every few seconds, a sync that re-downloads everything, a workflow that retries in a tight loop: each one looks harmless in a demo and hurts at real volume.

That is why we treat third-party limits as a product requirement from the first scoping conversation. Our senior US-based engineers map every integration, note its limits, and design caching, queues and safe retries into the build. Because you talk directly to the people writing the code, those decisions get made in a conversation, not lost between teams.

We also use AI-native tools like Claude Code, OpenAI Codex and Cursor to move quickly, which is how most of our projects ship in 6 to 10 weeks. Speed only helps if the result holds up under load, so we plan for it up front. If your Bubble or FlutterFlow app is hitting limits as you grow, a migration to custom code often gives you the control you need over batching, background jobs and retries.

Alex

Get help building an app that handles limits well

If your product relies on APIs for payments, CRM data, AI models or e-commerce, rate limits will shape how it behaves at scale. At Let’s Build My App, we design and build web and mobile apps with integration planning included, and we offer API and third-party integrations as part of our work.

Our published plans start at $1,750 per month for Starter, with Growth at $3,000 per month and Enterprise at $5,000 per month, plus a Custom option. You can see the details on our pricing page. If you are launching a first product, our MVP development service is built for speed. If your no-code app is straining under traffic or API usage, look at our Bubble-to-code migration. You can also scope your project and tell us what you want to launch.

FAQ

What are API rate limits?

API rate limits are caps on how many requests a user, key or app can send to an API within a given time window. Providers use them to prevent overload, keep usage fair, improve security and manage costs. When you pass the cap, the API rejects further requests until the window resets.

How do I fix the “API rate limit exceeded” error?

Read the Retry-After header and wait that long before retrying. If there is no header, use exponential backoff with a little random delay. Then reduce your call volume with caching, batching, webhooks and queues, or ask the provider about a higher limit or a higher plan.

What does HTTP 429 mean?

HTTP 429 means too many requests: you went over a limit set for your user or key. Azure’s guidance recommends returning 429 with retry guidance for user-limit breaches. A 503 is different: it signals that the service itself is constrained, not that you sent too much.

What is the best way to retry throttled requests?

Honor the provider’s retry guidance first, then use exponential backoff with jitter and a maximum number of attempts. For requests that create or change data, attach an idempotency key so a retry cannot repeat the action. Send read requests freely within the limit, but treat writes with care.

How should I choose limits for my own API?

Run load tests to find what your system can actually handle, then set limits at or below that validated level. Document them, return clear headers and errors, monitor how close traffic runs to the limit, and review the numbers on a regular schedule.

Sources

• What Is Rate Limiting? Dev Proxy, Microsoft Learn
• Design throttling to improve resilience, Microsoft Azure Well-Architected Framework
• REL05-BP02 Throttle requests, AWS Well-Architected Framework
• Scaling your API with rate limiters, Stripe
• What is API Rate Limiting? Postman Blog
• API Rate Limit Adoption: A pattern collection, ACM
• Rate limits for the REST API, GitHub Docs
• Rate Limits, Datadog API
• Shopify API limits
• Rate limits, OpenAI API
• Design a Distributed Scalable API Rate Limiter
• Idempotent APIs: Design, Keys and Versioning

Recommended

• Stop Leaking Keys: Secure Bubble API Connector and the :join Fix
• No-Code App Scalability: What Breaks First and How to Plan
• Fix Bubble Performance in 60 Minutes: Founder Playbook

About Let’s Build My App

Let’s Build My App is a US-based AI development agency. We design, build, and launch production-grade custom software using AI coding tools including Claude Code and OpenAI Codex, and we migrate legacy Bubble apps onto AI-coded stacks such as React, Supabase, and Firebase. We are the #1 US-Based Bubble Agency, founded and run by Alex Dow. Book a free strategy call to scope your project.