Sentry enforces rate limits on API requests to maintain stability for all users. The specific limits vary depending on your plan.
Every API response includes headers that tell you your current rate limit status:
| Header | Description |
|---|
X-Sentry-Rate-Limit-Limit | The total number of requests allowed in the current window. |
X-Sentry-Rate-Limit-Remaining | The number of requests you can still make in the current window. |
X-Sentry-Rate-Limit-Reset | Unix timestamp of when the current window resets. |
Handling 429 responses
When you exceed a rate limit, Sentry returns 429 Too Many Requests. The response includes a Retry-After header indicating how many seconds to wait before retrying.
import time
import requests
def get_issues(token, org):
resp = requests.get(
f"https://sentry.io/api/0/organizations/{org}/issues/",
headers={"Authorization": f"Bearer {token}"}
)
if resp.status_code == 429:
retry_after = int(resp.headers.get("Retry-After", 60))
time.sleep(retry_after)
return get_issues(token, org) # retry
return resp.json()
The example above retries indefinitely. In production code, set a maximum retry count to avoid infinite loops if the rate limit persists.
Best practices
Implement exponential backoff. If you receive a 429, wait at least the Retry-After duration before retrying. For repeated failures, increase the wait time between attempts.
Cache responses. Many Sentry resources — organization details, project configuration, team membership — change infrequently. Cache these locally and re-fetch on a schedule rather than on every request.
Use bulk endpoints. Wherever Sentry offers bulk operations (for example, bulk updating issues), prefer those over making many individual requests in a loop. This reduces your request volume and avoids triggering rate limits.
Read the headers proactively. Check X-Sentry-Rate-Limit-Remaining on every response. If the value is low, slow down your request rate before you hit the limit. 
