Rate Limits

The API enforces per-application rate limits to ensure fair usage and system stability. Limits are applied per external application, using a fixed 60-second window.

Limits

Limits are tracked separately per endpoint, so list, create, and read requests each have their own budget.

Response Headers

Every API response includes your current rate limit status:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1679529600

• X-RateLimit-Limit — the 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.

Rate Limit Exceeded

When you exceed a limit, the API responds with 429 Too Many Requests and a Retry-After header (seconds until you can retry):

Response: 429 Too Many Requests

Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1679529600

{
  "error": "rate_limit_exceeded",
  "message": "Too many requests. Please retry later."
}

Best Practices

• ✅ Read the X-RateLimit-Remaining header to pace your requests
• ✅ Respect the Retry-After header instead of retrying immediately
• ✅ Implement exponential backoff for retries
• ✅ Cache responses when appropriate
• ✅ Use webhooks instead of polling for updates
• ✅ Batch requests when possible

Next Steps

• API Endpoints - Available API endpoints
• Error Handling - Handle API errors