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