Glossary · Network and discovery
Rate limiting (APIs and agents)
Capping how many requests a client can make in a time window. HTTP servers refuse the excess with status 429, often with a Retry-After header.
Rate limiting is the practice of capping how many requests a client may make to a service in a given period, and refusing or delaying the excess.
How it works. The server chooses what to count by, such as an API key, an account, an authenticated agent or an IP address, and allows a set number of requests per window. Over the limit, an HTTP server answers with status 429 Too Many Requests (RFC 6585). The response may include a Retry-After header giving the delay in seconds or a date (RFC 9110). RFC 6585 deliberately leaves how the server identifies the client and counts requests to the server. Illustrative:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
Telling clients the limits. The IETF HTTPAPI working group is drafting two header fields, RateLimit-Policy and RateLimit, so a server can advertise its quota policy and how much remains before a client is throttled. As of September 2026 the document is an active Internet-Draft (revision 11) and has not been published as an RFC.
In A2A. The specification says agents should rate-limit all operations, return appropriate errors when a limit is exceeded, and may set different limits per operation or user tier. It lists “rate limit exceeded” among system errors, for which servers may include retry guidance such as Retry-After. It also tells agents to rate-limit to slow brute-force authentication attempts, and tells clients that receive push notifications to rate-limit to prevent webhook flooding. An extended Agent Card may describe rate limits and quotas to authenticated clients.
Why identity matters. A limit keyed on IP address is coarse. The Web Bot Auth draft notes that sites want to monitor and rate-limit per agent operator, and that IP addresses on cloud platforms bind poorly to any one operator. Limits keyed on an authenticated agent identity or credential can follow the agent itself, whichever addresses it uses.
Neighbouring terms. Bot detection often decides which limit a request falls under. Idempotency makes it safe to retry a request after a 429.
Sources
- RFC 6585: Additional HTTP Status Codes, section 4: 429 Too Many Requests (accessed )
- RFC 9110: HTTP Semantics, section 10.2.3: Retry-After (accessed )
- IETF draft: RateLimit header fields for HTTP (draft-ietf-httpapi-ratelimit-headers) (accessed )
- A2A Protocol Specification, section 13: Security Considerations (accessed )
- A2A Protocol Specification, section 3.3.2: Error Handling (accessed )
- IETF draft: HTTP Message Signatures for automated traffic (draft-ietf-webbotauth-httpsig-protocol) (accessed )