Rate Limits
All DevRadar API endpoints are rate-limited to ensure fair usage and system stability.Rate Limit Tiers
Rate Limit Headers
Every API response includes rate limit information:Example Headers
Rate Limit Error Response
When limits are exceeded, you’ll receive a429 status code:
Handling Rate Limits
Best Practices
- Check Headers - Always inspect rate limit headers
- Exponential Backoff - Implement retry with increasing delays
- Cache Responses - Store results to avoid repeated requests
- Batch Requests - Combine checks when possible
JavaScript Example
Python Example
Caching Strategy
To minimize API usage, implement caching:Client-Side Cache (JavaScript)
Server-Side Cache Recommendations
Increasing Rate Limits
Need higher limits for your application?Options
- Implement Caching - Reduces requests by 90%+
- Use Badges - Badges have higher limits and built-in caching
- Contact Us - Enterprise plans available with dedicated limits
Enterprise Inquiries
For production applications requiring higher throughput:- Email: [email protected]
- Subject: “API Rate Limit Request”
- Include: Use case, expected volume, timeframe
Rate Limit Calculations
Check Endpoint
- 60 requests/minute = 3,600 requests/hour
- With caching (90% hit rate): ~36,000 checks/hour effective
Scan Endpoint
- 10 requests/minute = 600 requests/hour
- Intended for periodic project analysis, not real-time use
Badge Endpoint
- 120 requests/minute = 7,200 requests/hour
- Badges are cached, so actual serving capacity is much higher
Monitoring Your Usage
Track these metrics to stay within limits:Monitoring Script
What’s Next
- Check Endpoint - Compatibility checking
- Errors - Error handling guide
- API Overview - API introduction
Questions about rate limits? Contact Support →