Rate limits

The authenticated API permits 60 requests per minute per authenticated user. Requests that cannot be associated with a user are limited by client IP address.

Response headers tell you how much of that allowance remains:

• X-RateLimit-Limit: maximum requests in the minute.
• X-RateLimit-Remaining: requests left in the current minute.
• Retry-After: seconds to wait; present on a 429 Too Many Requests response.
• X-Request-ID: identifier for this individual attempt.

Rate limits protect the service and can change as capacity and abuse controls evolve. Treat the response headers, rather than a hard-coded timer, as the source to follow.

Handle 429

Pause requests until Retry-After has elapsed. If further retries are needed, wait longer between attempts and add a random delay; this is exponential backoff with jitter. Set a maximum number of attempts or a time limit. A 429 does not mean the write ran successfully, but retry writes only when the operation is inherently idempotent or uses a documented key.

To make fewer requests, cache data that rarely changes, avoid fetching the same page repeatedly, and combine duplicate requests from your own workers. Use webhooks for supported events instead of repeatedly asking whether something changed.