Rate limits
To ensure our platform remains stable and fair for everyone, all APIs are rate-limited. We use a variety of strategies to enforce rate limits. We ask developers to use industry standard techniques for limiting calls, caching results, and re-trying requests responsibly.
💡
If an app reaches API rate limits for a specific resource, then it receives a 429 Too Many Requests response, and a message that a throttle has been applied.
| Throttle rate | Limit | Description |
|---|---|---|
| Burst | 200/min | Within 1 minute you are allowed a maximum on 200 requests |
| Sustained | 6000/h | During a 1 hour period in total you are allowed a maximum of 6000 requests |
| Attachments | 120/min | Specific limit for file uploads, documents and signatures endpoints combined |
| Time locations | 120/min | Specific limit for time locations endpoint |
Avoiding limits
Designing your app with best practices in mind is the best way to avoid throttling errors. For example, you can stagger API requests in a queue and do other processing tasks while waiting for the next queued job to run. Consider the following best practices when designing your app:
- Optimize your code to only get the data that your app requires.
- Use caching for data that your app uses often.
- Regulate the rate of your requests for smoother distribution.
- Include code that catches errors. If you ignore these errors and keep trying to make requests, then your app won’t be able to gracefully recover.
- Your code should stop making additional API requests until enough time has passed to retry. The recommended backoff time is 1 second.