Sentry rate limits every API request made to prevent abuse and resource overuse. The limit is applied to each unique combination of caller and endpoint.
We restrict both how frequently a request is made (requests per second rate limit) and how many concurrent requests a caller can make (concurrent rate limit).
The requests per second rate limit follows a fixed window approach. Requests are counted into time buckets, determined by the window size. If the number of requests from a caller exceeds the number of allowed requests within a window, then that request will be rejected. While there is a default rate limit of 40 requests per second, each endpoint can have their own maximum number of requests and window size.
Meanwhile, the concurrent rate limiter will reject requests if the caller has too many requests in progress at the same time.
You can track your rate limit usage by looking at special headers in the response.
Every API request response includes the following headers:
- The maximum number of requests allowed within the window
- The number of requests this caller has left on this endpoint within the current window
- The time when the next rate limit window begins and the count resets, measured in UTC seconds from epoch
- The maximum number of concurrent requests allowed
- The number of concurrent requests this caller has left
The rate limiter looks at the caller's identity instead of the bearer
Polling the API for updates is likely to quickly trigger rate limiting. We recommend using our webhooks, if possible.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").