Overview
Every API request is rate-limited based on the type of operation. Limits are applied per authenticated user (or per IP for unauthenticated requests) using a sliding window algorithm.Rate Limit Tiers
| Tier | Limit | Window | Typical Endpoints |
|---|---|---|---|
read | 300 requests | 1 minute | GET endpoints (list, retrieve) |
write | 30 requests | 1 minute | POST, PUT, PATCH, DELETE |
ai | 5 requests | 1 minute | AI quiz generation |
render | 10 requests | 1 hour | Video render requests |
Response Headers
Every successful response includes rate limit headers:| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window |
X-RateLimit-Remaining | Requests remaining in the current window |
X-RateLimit-Reset | Unix timestamp (seconds) when the window resets |
Handling 429 Responses
When you exceed the rate limit, the API returns a429 Too Many Requests response in RFC 9457 Problem Details format with a Retry-After header:
Best Practices
Use the Retry-After Header
Always respect the Retry-After header value. It tells you exactly how many seconds to wait before retrying.
Implement Exponential Backoff
For robust integrations, combineRetry-After with exponential backoff:
Monitor Your Usage
CheckX-RateLimit-Remaining proactively. When it drops below 10% of your limit, slow down requests to avoid hitting the ceiling.
Batch Where Possible
Reduce request count by using list endpoints with appropriatelimit values instead of fetching resources one at a time. See Pagination for details on efficient data retrieval.