Rate Limits Overview
THEITBULLS APIs enforce rate limits to ensure fair usage and protect the platform from abuse. Rate limits are applied per API key and vary based on your subscription plan.
Important: Exceeding rate limits will result in
429 Too Many Requests responses. Implement exponential backoff to handle these errors gracefully.
Rate Limit Headers
Every API response includes headers that show your current rate limit status:
# Response Headers X-RateLimit-Limit: 100 X-RateLimit-Remaining: 97 X-RateLimit-Reset: 1614556800 X-RateLimit-Plan: business
| Header | Description |
|---|---|
X-RateLimit-Limit |
Maximum number of requests allowed |
X-RateLimit-Remaining |
Number of requests remaining |
X-RateLimit-Reset |
Unix timestamp when the limit resets |
X-RateLimit-Plan |
Your current subscription plan |
Rate Limits by Plan
| Plan | Requests/Second | Requests/Day |
|---|---|---|
| Starter | 10 | 10,000 |
| Business | 50 | 100,000 |
| Enterprise | Custom | Custom |
Handling Rate Limit Errors
When you exceed your rate limit, the API returns a 429 Too Many Requests error. Here's how to handle it:
# Example 429 Response HTTP/1.1 429 Too Many Requests Content-Type: application/json X-RateLimit-Limit: 100 X-RateLimit-Remaining: 0 X-RateLimit-Reset: 1614556800 Retry-After: 3600 { "error": "rate_limit_exceeded", "message": "Rate limit exceeded. Please try again after 3600 seconds.", "retry_after": 3600 }
Exponential Backoff
Implement exponential backoff with jitter to handle rate limit errors gracefully:
# JavaScript example with exponential backoff async function makeRequestWithRetry(url, options, maxRetries = 5) { for (let i = 0; i < maxRetries; i++) { try { const response = await fetch(url, options); if (response.status === 429) { const retryAfter = response.headers.get('Retry-After') || Math.pow(2, i) * 1000; await delay(retryAfter * 1000); continue; } return response; } catch (error) { if (i === maxRetries - 1) throw error; await delay(Math.pow(2, i) * 1000); } } }
Best Practices
- Monitor headers: Always check
X-RateLimit-Remainingto stay within limits - Implement exponential backoff: Use jitter to avoid thundering herd problems
- Batch requests: Use batch endpoints when available to reduce API calls
- Cache responses: Cache frequently accessed data to reduce API calls
- Spread requests: Distribute requests evenly across time windows
- Use webhooks: Receive events in real-time instead of polling
Pro tip: The
Retry-After header tells you exactly how long to wait before retrying. Always respect it to avoid further rate limiting.
Rate Limit Increase
Need higher rate limits? Contact our sales team to discuss custom limits for your use case:
- Business Plan: Up to 100 req/sec with volume discounts
- Enterprise Plan: Custom limits tailored to your needs
- Dedicated Infrastructure: Isolated resources for high-volume customers
Need higher rate limits? Contact our team.
Contact Sales