Ergast API Rate Limits
The Ergast F1 API enforces the following rate limits to ensure fair usage:- Burst Limit: 4 requests per second
- Sustained Limit: 200 requests per hour
Rate Limiting Implementation
All data collection scripts in the F1 Stats Archive implement rate limiting to respect the API’s constraints.Basic Rate Limiting Pattern
Here’s the simple approach used inevents.py:
Using
time.sleep(0.3) ensures approximately 3.3 requests per second, safely below the 4 req/sec limit.Advanced Rate Limiting Pattern
Theresults.py script uses a class-based approach with precise timing:
- Tracks the exact time of the last request
- Calculates the minimum wait time dynamically
- Ensures precise adherence to the 4 req/sec limit
Retry Logic for 429 Responses
Thelaptimes.py script demonstrates robust retry logic:
This implementation handles pagination while maintaining rate limits, important for endpoints that return large datasets.
Best Practices
1. Use Conservative Delays
Stay well below the maximum rate limit:2. Implement Exponential Backoff
For production systems, use exponential backoff:3. Monitor Request Counts
Track how many requests you’re making per hour:4. Cache API Responses
Avoid redundant requests by caching:Handling Large Data Collections
When collecting historical data for multiple seasons:Batch Processing
Progress Tracking
Rate Limit Headers
The Ergast API doesn’t return rate limit headers, so you must track limits client-side using the patterns shown above.Testing Rate Limits
Test your rate limiting implementation:Troubleshooting
Still Getting 429 Errors
- Increase the delay between requests
- Check if you have multiple processes running
- Verify you’re not making concurrent requests
- Implement longer backoff periods (60-120 seconds)
Slow Data Collection
With rate limits, collecting complete historical data takes time:- 4 req/sec = 240 requests/minute
- 200 req/hour sustained
- Full season (24 races × 8 endpoints) = 192 requests
- Multiple seasons will take hours to complete