Skip to content
Dashboard

Rate Limits

LimitValue
Sustained1,000 requests per minute per API key
Burst50 requests per second per API key

Rate limits are enforced per API key. The sustained limit is measured over a rolling 60-second window.

Every authenticated response includes rate limit headers regardless of whether you are near the limit:

HeaderDescription
X-RateLimit-LimitTotal requests allowed in the current window
X-RateLimit-RemainingRequests remaining in the current window
X-RateLimit-ResetUnix timestamp (seconds) when the window resets

These headers are not present on 401 responses (unauthenticated requests).

A rate-limited response has status 429 and includes a Retry-After header:

HTTP/1.1 429 Too Many Requests
Retry-After: 14
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1720000000
{
"error": {
"type": "rate_limit_error",
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded. Retry after 14 seconds."
},
"meta": { "requestId": "req_01j..." }
}

The Retry-After value is in seconds. Do not retry before this time elapses.

For automated clients, implement token-bucket or exponential backoff:

  1. Check X-RateLimit-Remaining on each response. If it is below a threshold (for example, 50), slow your request rate proactively.
  2. On a 429, wait exactly Retry-After seconds before the next request to that resource.
  3. For burst scenarios, spread requests evenly rather than sending them all at once.
Terminal window
# Example: polling with a pause between requests
while true; do
response=$(curl -s -w "\n%{http_code}" \
-H "Authorization: Bearer sk_test_your_key_here" \
https://api-us.suiteop.com/api/v1/tasks)
status=$(echo "$response" | tail -1)
if [ "$status" = "429" ]; then
retry_after=$(curl -s -I \
-H "Authorization: Bearer sk_test_your_key_here" \
https://api-us.suiteop.com/api/v1/tasks \
| grep -i retry-after | awk '{print $2}' | tr -d '\r')
sleep "${retry_after:-10}"
fi
sleep 0.1 # max ~10 req/s sustained — well within limits
done