Rate Limits
Understanding API rate limits, tiers, and best practices for optimal usage
Rate Limiting Overview
Time Windows
Rate limits are calculated per minute, hour, and day
Fair Usage
Prevents abuse while ensuring reliable service
Scalable Tiers
Higher limits available with premium plans
Graceful Handling
Clear error messages when limits are exceeded
Rate Limit Strategy
Our rate limiting uses a sliding window approach with burst allowances. This ensures fair access while allowing for occasional traffic spikes within reasonable limits.
Rate Limit Tiers
F
Free
$0/month
Wallet Analysis:10/hour
Risk Assessment:5/hour
Batch Processing:Not available
Real-time Monitoring:Not available
P
Pro
$49/month
Wallet Analysis:100/hour
Risk Assessment:50/hour
Batch Processing:10/hour
Real-time Monitoring:5 addresses
E
Enterprise
Custom
Wallet Analysis:1000/hour
Risk Assessment:500/hour
Batch Processing:100/hour
Real-time Monitoring:Unlimited
Rate Limit Headers
Every API response includes rate limit headers to help you track your usage and avoid hitting limits.
| Header | Description | Example |
|---|---|---|
| X-RateLimit-Limit | The maximum number of requests allowed in the current window | 100 |
| X-RateLimit-Remaining | The number of requests remaining in the current window | 85 |
| X-RateLimit-Reset | Unix timestamp when the rate limit window resets | 1642694400 |
| X-RateLimit-Window | The duration of the rate limit window in seconds | 3600 |
Example Response Headers
HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 85
X-RateLimit-Reset: 1642694400
X-RateLimit-Window: 3600
Content-Type: application/json
{
"analysis_id": "ana_1234567890",
...
}Best Practices
Monitor Headers
Always check rate limit headers in responses
- Parse X-RateLimit-Remaining before making requests
- Use X-RateLimit-Reset to plan request timing
- Implement client-side rate limit tracking
Implement Backoff
Use exponential backoff when limits are hit
- Start with 1-second delays
- Double delay time on subsequent 429 errors
- Add jitter to prevent thundering herd
Handle 429 Errors
Gracefully handle rate limit exceeded responses
- Check Retry-After header for wait time
- Queue requests instead of dropping them
- Provide user feedback about delays
Optimize Usage
Maximize efficiency within your limits
- Batch requests when possible
- Cache results to avoid duplicate calls
- Use webhooks for real-time updates
Rate Limit Exceeded Response
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1642694400
{
"error": {
"code": "RATE_LIMIT_EXCEEDED",
"message": "Rate limit exceeded. Try again in 60 seconds."
}
}