Rate Limits
Rate Limit Tiers
Section titled “Rate Limit Tiers”API rate limits are based on your subscription plan:
| Plan | Requests per Minute | Daily Limit |
|---|---|---|
| Free | 60 | 10,000 |
| Pro | 300 | 100,000 |
| Enterprise | 1,000 | Unlimited |
Limits are applied per API key using a sliding window algorithm.
Rate Limit Headers
Section titled “Rate Limit Headers”Every API response includes rate limit information:
X-RateLimit-Limit: 300X-RateLimit-Remaining: 297X-RateLimit-Reset: 1705312800| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests per window |
X-RateLimit-Remaining | Requests remaining in current window |
X-RateLimit-Reset | Unix timestamp when the window resets |
Handling 429 Responses
Section titled “Handling 429 Responses”When you exceed the rate limit, the API returns HTTP 429:
{ "code": "RATE_LIMIT_EXCEEDED", "message": "Too many requests. Please retry after 45 seconds.", "retry_after_secs": 45}The Retry-After header is also included (in seconds).
Recommended Retry Strategy
Section titled “Recommended Retry Strategy”async function apiCallWithRetry(url: string, options: RequestInit, maxRetries = 3) { for (let attempt = 0; attempt < maxRetries; attempt++) { const response = await fetch(url, options);
if (response.status === 429) { const retryAfter = parseInt(response.headers.get('Retry-After') || '60', 10); await new Promise(resolve => setTimeout(resolve, retryAfter * 1000)); continue; }
return response; }
throw new Error('Max retries exceeded');}Best Practices
Section titled “Best Practices”- Cache responses — Reduce API calls by caching data that doesn’t change frequently
- Use webhooks — Subscribe to events instead of polling for changes
- Batch operations — Use bulk endpoints when available
- Respect Retry-After — Always wait the indicated time before retrying