Rate Limits
Learn about requests per second limits, team-based restrictions, and best practices.
Rate limits control how many API requests your team can make each second.
Why rate limits are important ?
Rate limits are a common practice for APIs, and they're put in place for a few different reasons:
- Prevent abuse. A flood of requests can disrupt the API.
- Keep access fair. Heavy usage from one client should not slow down requests from others.
How do they work ?
Limits are measured in requests per second (RPS). Requests that exceed the limit receive HTTP 429.
All requests from your team share the same limit. Heavy usage by one member can affect the rest of the team.
How to mitigate rate limits error ?
Use webhooks to receive processing updates without repeatedly polling the API.
If a request is rate limited, wait before retrying and increase the delay after each failed attempt.
Retrying with exponential backoff
With exponential backoff, each retry waits longer than the previous one. Add a random delay, called jitter, so clients do not all retry at once. Stop when the request succeeds or you reach your retry limit.
- Automatic retries help your application recover from temporary rate limits.
- Short initial delays allow a quick retry, while longer delays give the API time to recover.
- Jitter spreads retries across clients.
Note that unsuccessful requests contribute to your per-second limit, so continuously resending a request won’t work.