API rate limits: the thing nobody talks about until it hits them

OpenAI logged eleven incidents in January 2026. One every two to three days.

If your automation depends on an external API, you likely have a risk you have not yet named.

How rate limits hit

They tend to surface in two ways.

First: Automation works in testing and staging because data volumes are small. In production you run the same calls for 500 users per hour and receive 429 responses (Too Many Requests) you had not planned for. The script fails, nobody notices, data goes unprocessed.

Second: An external service changes its limits without notice. Or you add one new use case that doubles your call volume. Both happen to most people eventually.

41% of API security incidents in 2025 involved rate limits in some form. The problem is not only attackers: your own automations can cause it just as easily.

Three things to check right now

1. Read the documentation properly

What is the maximum number of calls per minute? Per hour? Per day? Is there a burst limit that differs from the base limit? Is the limit per API key or per organisation?

These details are in the documentation but easy to skip early on. Write down the numbers and calculate how close your automation will come to them in production.

2. Build retry logic from the start

When you receive a 429, wait and try again. Exponential backoff is the standard: first retry after 2 seconds, second after 4, third after 8.

Without this, every rate limit hit becomes a manual incident. Adding it after the fact is much harder than building it in from the beginning.

3. Monitor call volume

If you do not know how many API calls your automation makes per day, you will not notice when you are approaching the limit. Log call counts, track trends, and set an alert when you reach 80% of the limit.

Why this matters

Rate limits do not disappear. They grow with your automation. As user counts grow or new features are added, call volume increases. Without a plan, the production issue arrives without warning.

The best time to account for rate limits is during design, not when the automation is already running in production.

Want to review your automations for rate limit readiness? Get in touch.