Concepts

Rate Limits

Limits are enforced per API key and vary by endpoint — authentication endpoints in particular are far stricter than general API traffic, since they're the most common target for abuse.

Auth endpoints

Login, registration, password reset, and email verification are limited per IP (and per user, for verification resends) on a tight window — typically a handful of requests per 15 minutes. Each endpoint's reference page states its exact limit under Errors.

API keys

Every API key has its own configurable limit, checked on every request that uses it. Check your key's current limit, remaining requests, and reset time at any time:

Name	Type	Required	Description
`limit`	number	No	Requests allowed in the current window.
`remaining`	number	No	Requests left before the next reset.
`resetAt`	string (ISO 8601)	No	When the window resets.

http

GET /api/api-keys/{id}/usage
Authorization: Bearer YOUR_JWT

# => { "rateLimit": { "limit": 10000, "remaining": 8500, "resetAt": "2026-07-25T00:00:00.000Z" }, ... }
GET /api/api-keys/{id}/usage
Authorization: Bearer YOUR_JWT

# => { "rateLimit": { "limit": 10000, "remaining": 8500, "resetAt": "2026-07-25T00:00:00.000Z" }, ... }

Data mutations

Collection writes are additionally subject to a per-project mutation limit (maxExecutionsPerMinute / maxExecutionsPerHour), configurable from the Console independently of your API key's general limit.

Handling 429

Any exceeded limit returns 429 Too Many Requests. Retry after the period indicated in the Retry-After header, or implement exponential backoff — see Error Explorer for the full RATE_LIMITED response shape and every endpoint that can return it.

Tip

Building a client that retries automatically? See Error Handling for a backoff implementation.