Rate limiting is a mechanism used to control the number of requests a user or application can make to our API within a specific time frame. This helps ensure fair access, system stability, and a consistent experience for all users.
What is Rate Limiting?
Rate limiting defines how many requests can be made in a given time window. If this limit is exceeded, the system may delay or reject additional requests, often returning an HTTP 429 "Too Many Requests" error.
Why is Rate Limiting required?
Prevents abuse or excessive use
Ensures availability for all users
Protects backend services from overload
Helps mitigate automated or high-volume traffic
Supports consistent and reliable API performance
How does Rate Limiting work?
Each user or system is monitored based on identity (like API key or IP address). Requests are counted over time. If the allowed threshold is reached, further requests may be rejected.
How do I know if I’ve reached the Rate Limit?
Requests exceeding the Rate Limit receive an HTTP 429 'Too Many Requests' response - an example is provided below. This may include a Retry-After header telling you when to try again.
Example Response:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
What to do if I've reached the Rate Limit?
To handle 429 Errors (too many requests), avoid or manage rate limits, distributors are encouraged to:
Spread out your requests rather than sending them in bursts
Implement retry logic using exponential backoff
Respect the Retry-After 60 seconds header in 429 responses
Cache responses to reduce redundant API calls
Use batching to combine multiple requests
Monitor your request volume and adjust as needed
Rate Limiting best practices
Plan your request volume based on expected usage
Use caching and avoid unnecessary calls
Implement a retry logic with delays
Use pagination or batching to reduce volume
Monitor for 429 responses and take corrective action
Avoid traffic spikes and distribute requests evenly
Frequently Asked Questions
What should my application do when it receives a 429 response?
You should pause further requests, honour the Retry-After header, and implement exponential backoff before retrying.
Will rate limits change over time?
Yes, our Rate Limits may change over time. Rate Limits may be adjusted based on system performance, usage patterns, or changes to the API platform. We recommend building flexibility into your integrations.
Are retries guaranteed to succeed?
No-even with backoff logic, retry attempts may still hit limits if usage remains too high. It’s important to monitor and control request volumes.