Skip to main content

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
Exceeding these limits will result in HTTP 429 (Too Many Requests) responses. Your requests will be throttled until the rate limit window resets.

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 in events.py:
Using time.sleep(0.3) ensures approximately 3.3 requests per second, safely below the 4 req/sec limit.

Advanced Rate Limiting Pattern

The results.py script uses a class-based approach with precise timing:
This approach:
  • 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

The laptimes.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.
Always implement both burst (per-second) and sustained (per-hour) rate limiting when making multiple requests.

Testing Rate Limits

Test your rate limiting implementation:

Troubleshooting

Still Getting 429 Errors

  1. Increase the delay between requests
  2. Check if you have multiple processes running
  3. Verify you’re not making concurrent requests
  4. 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
Be patient and let automated workflows handle gradual updates.