Reference

Rate limits

Rate limits protect the API from excessive traffic. Limits are applied per API key and reset on a sliding window. Exceeding the limit returns 429 Too Many Requests.

Limits by plan

Rate limits are tied to the workspace plan:

  • Creator: 100 requests per minute.
  • Pro: 500 requests per minute.
  • Admin bypass: same as Pro (500 req/min).

Limits apply per API key, not per workspace. If you need higher throughput, upgrade your plan or distribute requests across multiple keys.

Rate limit headers

Every response includes rate limit headers so you can track usage programmatically:

  • X-RateLimit-Limit: the maximum requests per minute for this key.
  • X-RateLimit-Remaining: the number of requests remaining in the current window.
  • X-RateLimit-Reset: the Unix timestamp when the window resets.
Handling rate limits

When the limit is exceeded, the API returns 429 Too Many Requests with the standard error shape:

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Rate limit exceeded. Retry after the time specified in Retry-After."
  }
}

The response also includes a Retry-After header with the number of seconds to wait before retrying. Respect this header to avoid additional 429 responses.

Best practices
  • Monitor X-RateLimit-Remaining and slow down when it drops below 10% of the limit.
  • Implement exponential backoff when you receive a 429 response.
  • Batch operations where possible. Creating 10 posts in 10 sequential requests consumes 10 times the rate limit of a bulk operation.
  • Use separate API keys for separate integrations so one noisy consumer does not starve another.