What to Do If You're Being Rate Limited
How rate limiting works, what triggers a 429 error, and how to handle it in your integration.
Rate limiting controls how many API requests you can make within a specific time window. It's designed to ensure stable performance for all users.
Rate limit thresholds
- 300 requests per minute sustained
- 1,500 requests burst capacity over a 5-minute window
- No concurrency limits — parallel requests are allowed
How it works: token bucket
Think of your rate limit as a bucket holding up to 1,500 tokens:
- Each API request consumes 1 token
- The bucket refills at 300 tokens per minute
- You can make requests as fast as you want as long as tokens are available
Example: After making 1,000 quick requests from a full bucket:
| Time | Tokens available |
|---|---|
| Immediately | 500 |
| +1 minute | 800 |
| +2 minutes | 1,100 |
| +3 minutes | 1,400 |
| +5 minutes | 1,500 (full) |
The Retry-After header in 429 responses tells you exactly when your tokens will be replenished.
How to know you're being rate limited
- HTTP 429 Too Many Requests error responses
- Delays or failures in API responses
- Warnings in your dashboard or logs
What to do
- Pause and retry — rate limits reset quickly; wait a few seconds then retry
- Use exponential backoff — build in delays between automated requests to avoid hitting the limit repeatedly
- Optimize your calls — lower
page_size, avoid duplicate calls, and test with smaller datasets before scaling up - Upgrade your plan — if you're consistently hitting limits, a higher plan may better fit your throughput needs
Parallel requests
There are no concurrency limits. You can send multiple requests simultaneously as long as you stay within the 300 requests/minute cap. Multi-threaded and async patterns are fully supported.
Need help?
Message us via live chat or email [email protected] if you need help adjusting your setup.