Rate Limits
Rate limit tiers, response headers, and how to implement retry logic.
Limits by tier
Standard
60 req/min
20 req/sec burst
Per API key — all plans
Pro / Scale
300 req/min
50 req/sec burst
Available on Pro plans
Enterprise
Custom
Custom burst
Contact sales
Rate limits are applied per API key, not per organisation. If you have multiple keys, each has its own independent limit.
Rate limit response headers
Every API response includes these headers:
X-RateLimit-LimitYour maximum requests allowed per minute.X-RateLimit-RemainingRequests remaining in the current minute window.X-RateLimit-ResetUnix timestamp (UTC) when the current window resets.Retry-AfterOnly present on 429 responses. Seconds to wait before retrying.Handling 429 Too Many Requests
When you exceed the rate limit, the API returns HTTP 429. The response body contains an error object with a retryAfter field in seconds. Implement exponential backoff:
# Exponential backoff (JavaScript):
async function fetchWithRetry(url, options, attempt = 1) {
const res = await fetch(url, options);
if (res.status === 429 && attempt <= 5) {
const delay = Math.pow(2, attempt) * 1000; // 2s, 4s, 8s…
await new Promise(r => setTimeout(r, delay));
return fetchWithRetry(url, options, attempt + 1);
}
return res;
}
Best practices to avoid rate limiting
- Cache API responses locally and invalidate via webhooks instead of polling.
- Use the bulk endpoints (/api/v1/matters/bulk, /api/v1/contacts/bulk) for large data operations.
- Spread requests across time instead of bursting all at once on startup.
- Monitor the X-RateLimit-Remaining header and slow down proactively when it drops below 10.
- Use webhooks for real-time updates instead of polling the API on a schedule.