Rate limiting
Rate limiting restricts how many requests a client may make to an API within a given window, enforced per API key, user, IP address, or endpoint. When a client exceeds the limit, the API typically responds with HTTP 429 (Too Many Requests), often accompanied by headers reporting the limit, the remaining quota, and when to retry.
Agents hit rate limits faster than humans do. An agent iterating a list, fanning out parallel requests, or retrying failures can exhaust a quota in seconds that a human integrator would never approach. Documented limits let an agent pace itself deliberately; undocumented limits surface as apparently random failures the agent cannot reason about.
The documentation an agent needs is specific: the numeric limits per tier or endpoint, the headers that report remaining quota (commonly `RateLimit-*` or `X-RateLimit-*` families), and whether a 429 carries a `Retry-After` header. With those facts, an agent can implement correct backoff on its own; without them, it guesses.
Rate-limit documentation also interacts with cost. An agent that cannot learn the limits from the docs discovers them by burning requests — and its operator's budget — at runtime.
Discry records whether rate limits are documented as one of the execution-documentation facts on an API's profile ('Rate limits documented'). This is a fact about the public documentation surface — whether an agent reading the docs can learn the limits before hitting them — not a test of the enforcement itself.
What does an AI agent make of your API?
Find out in about a minute — no signup.
Discry your API — free