Rate Limits
Requests are throttled per authenticated user using a sliding-window counter. Limits reset on a rolling 60-second window.
Limits by tier
| Tier | Limit | Window |
|---|---|---|
| Authenticated user | 60 requests | 60 seconds |
| Unauthenticated / IP | 20 requests | 60 seconds |
Response headers
Every API response includes these headers so your client can track budget without waiting for a 429.
| Header | Description |
|---|---|
| X-RateLimit-Limit | Maximum requests allowed in the window |
| X-RateLimit-Remaining | Requests remaining in the current window |
| X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
| Retry-After | Seconds to wait — only present on 429 responses |
Handling 429 Too Many Requests
429
Too Many Requests
Read the Retry-After header value (seconds) and wait before retrying.
# Example exponential-backoff snippet (Node.js)
async function fetchWithRetry(url, opts, attempt = 0) {
const res = await fetch(url, opts)
if (res.status === 429) {
const wait = (res.headers.get("Retry-After") ?? 2 ** attempt) * 1000
await new Promise(r => setTimeout(r, wait))
return fetchWithRetry(url, opts, attempt + 1)
}
return res
}
Implementation notes
- Rate limiting uses an in-memory sliding-window counter — Vercel-compatible, no Redis required.
- Each Vercel serverless instance maintains its own counter, so actual throughput across instances may be higher.
- Limits are applied per user ID, not per workspace or per endpoint.