Rate limits
120 requests per minute per token, with bursts, and headers that tell you where you stand.
Each personal access token may make 120 requests per minute. The limit is a token bucket: a token starts with a full bucket of 120 requests, so short bursts are fine, and the bucket refills steadily at 2 requests per second.
Headers
Every response to a request made with a personal access token carries:
| Header | Meaning |
|---|---|
X-RateLimit-Limit | Requests allowed per minute (120). |
X-RateLimit-Remaining | Requests left in the bucket right now. |
X-RateLimit-Reset | Seconds until the bucket is full again. |
Over the limit
When the bucket is empty, the API answers 429 Too Many Requests with the code rate_limited
and a Retry-After header: the number of seconds to wait before trying again.
HTTP/2 429
retry-after: 1
x-ratelimit-limit: 120
x-ratelimit-remaining: 0
x-ratelimit-reset: 60
{ "code": "rate_limited", "message": "Too many requests. Try again in a moment." }A well-behaved client:
- waits
Retry-Afterseconds before retrying a429(retrying transaction creates is always safe) - slows down when
X-RateLimit-Remaininggets low, instead of running into the wall
async function call(url, init) {
for (;;) {
const res = await fetch(url, init);
if (res.status !== 429) return res;
const wait = Number(res.headers.get('Retry-After') ?? '1');
await new Promise((r) => setTimeout(r, wait * 1000));
}
}Approximate, for now
Limits are tracked in memory on each server instance, not shared between instances. Under load
you may occasionally get a little more than 120 requests per minute through, and a limit can
reset early. Don't rely on the exact numbers; do respect 429 and Retry-After.
Who is limited
Only personal access tokens are limited this way. Browser and mobile-app sessions aren't (signing in and password requests have their own protections against abuse).