What should our software do when it is refused?

Wait and try again, lengthening the wait after each refusal, and stop after a sensible number of attempts rather than for ever. Providers usually indicate how long to wait, and honouring that is both more effective and more polite than guessing. Retrying immediately is the one response that reliably makes things worse.

Can we get the limit raised?

Often, and it usually rises with your tier as well. Providers generally have a process for requesting more, and it goes better when you can describe the workload and when you ask before you need it. Discovering the ceiling during a deadline is the expensive version of this conversation.

Why did we hit one when nothing changed?

Most likely something else on the same account was running at the same time. The allowance is shared across everything using those credentials, so a scheduled job overlapping with a team's ordinary work is the classic case. Separate credentials for separate uses turns that from a mystery into a line in a log.

Glossary

Rate limits

A rate limit caps how many requests you may send in a given period, so a system that asks too quickly is refused until the period passes, which protects the service and sets the pace of any automated job.

In plain terms

There is a queue and it has a speed limit. Ask faster than the limit allows and you are politely turned away rather than served, and you try again shortly. It is not a punishment and it does not mean anything is broken. It is the same mechanism a bank's website uses to stop one visitor consuming everything, applied to something you are paying for.

Why it matters

It decides how long a bulk job takes, which is a planning fact rather than a technical one. A task over ten thousand documents finishes in an hour or overnight depending entirely on this number, and finding that out during the run is worse than finding it out beforehand. It is also one of the more common reasons an automation that worked perfectly in testing fails the first time it meets real volume.

How it works

The cap is usually expressed per minute and sometimes over longer periods as well, and providers frequently count more than one thing: how many requests you sent and how much text those requests carried. Hitting either produces the same refusal, so a job sending few but very large requests can be stopped by a limit it appeared to be nowhere near.

The refusal is a specific, expected reply rather than an error in the ordinary sense. Well-built software recognises it, waits, and tries again, lengthening the wait each time it is refused. Software that treats it as a failure either gives up on work it should have completed or retries immediately and makes the situation worse.

Limits are usually tied to your account and your tier, so they rise as you commit more, and providers will often raise one on request if you can say what you are doing. That conversation is far easier before a deadline than during one.

Running several things at once shares the same allowance. Two automations, a batch job and a team of people all working through the same account draw on one pool, which is why a job that ran fine at seven in the morning is refused at ten. Separate credentials for separate uses make that visible rather than mysterious.

Two responses to the same refusal

Both columns describe the same moment: a request arrives faster than the agreement allows and is refused. The left column treats that as an expected reply, waits a little, waits longer if it happens again, and completes the work slightly behind schedule while recording how often it was held up, which is useful information for the next capacity conversation. The right column treats it as a failure, retries immediately, and by doing so makes itself more likely to be refused again, before eventually giving up somewhere in the middle of a batch with no clear record of what was and was not done. Nothing distinguishes the two situations except the handling, which is why this is worth asking a vendor about specifically: not whether their product has limits, but what it does when it meets one.

Seen in the wild

Run an automation over a few hundred records in one go and watch where it starts being refused, which is the number you needed before you planned the job.
n8n
Read the documented limits for the route you intend to use rather than the one you tested with, since they frequently differ between tiers.
OpenRouter
Batch a large job into steps with a pause between them, which is the ordinary shape of any bulk task that has to live inside a cap.
Make

Common misconceptions

People assume

Being refused means something is wrong.

In fact

It means you asked faster than the agreement allows, which is a normal reply that well-built software expects and handles. Treating it as an outage leads people to escalate a working system, and treating it as a reason to retry immediately turns a brief pause into a longer one.

People assume

It only matters for developers.

In fact

It decides how long your bulk job takes and whether your automation survives a busy Monday, which are operational facts rather than technical ones. Anybody planning to process a large batch on a deadline needs the number before they plan, whoever writes the code.

Telling them apart

Rate limits vs Usage limits

Rate limits

How fast. A cap per minute or hour, which delays work rather than preventing it, and which resets almost immediately.

Usage limits

How much. A ceiling over a day, week or month, which eventually stops you or moves you to something weaker.

If waiting fixes it, it was the first. If waiting until next month fixes it, it was the second, and they are frequently confused because both arrive as a refusal.

Questions

What should our software do when it is refused?: Wait and try again, lengthening the wait after each refusal, and stop after a sensible number of attempts rather than for ever. Providers usually indicate how long to wait, and honouring that is both more effective and more polite than guessing. Retrying immediately is the one response that reliably makes things worse.
Can we get the limit raised?: Often, and it usually rises with your tier as well. Providers generally have a process for requesting more, and it goes better when you can describe the workload and when you ask before you need it. Discovering the ceiling during a deadline is the expensive version of this conversation.
Why did we hit one when nothing changed?: Most likely something else on the same account was running at the same time. The allowance is shared across everything using those credentials, so a scheduled job overlapping with a team's ordinary work is the classic case. Separate credentials for separate uses turns that from a mystery into a line in a log.

Key takeaways

It caps how fast you may ask, not how much you may do in total.
Providers often count both requests and the amount of text in them, so either can stop you.
A refusal is an expected reply; wait, lengthen the wait, and try again.
The number decides how long a bulk job takes, which makes it a planning fact.
The allowance is shared across everything using the same credentials.

Tools that use this

n8n
A bulk run is where the number stops being theoretical.
OpenRouter
Documented limits that differ between tiers.
Make
Batching with pauses, the ordinary shape of a job inside a cap.

Last checked July 2026

All glossary terms