What is a rate limit?

Rate limit, explained#

Every API has a capacity, and without limits one runaway script or misbehaving agent can use it all. Rate limits share the capacity fairly and make abuse expensive. They are usually counted per credential, so two integrations owned by the same person do not compete, and sometimes per IP address for unauthenticated requests.

The common algorithms are fixed windows (count requests per calendar minute), sliding windows (count over the last sixty seconds) and token buckets (a bucket refills at a steady rate and each request takes a token, which allows short bursts). Many APIs keep a stricter budget for writes than for reads, because writes cost more and do more damage when they go wrong.

The response for an exceeded limit is 429 Too Many Requests, defined in RFC 6585, with a Retry-After header (RFC 9110) giving seconds to wait or a date. Some APIs also send headers showing the remaining budget so clients can slow down before they hit the wall.

A well-behaved client respects Retry-After instead of retrying immediately, backs off exponentially with some random jitter for other temporary failures, and spreads bulk work out rather than sending it all at once. AI agents need this as much as scripts do: an agent that loops on a refused call can burn a whole minute's budget in seconds.

For example, an import script creates 200 issues in a loop. After the thirtieth write in a minute, the API answers 429 with Retry-After: 17. The script sleeps 17 seconds and continues, and the import finishes in a few minutes instead of failing halfway.