> ## Documentation Index
> Fetch the complete documentation index at: https://sentrydocs.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate Limits

> Understand API rate limits and how to handle them

Sentry enforces rate limits on API requests to maintain stability for all users. The specific limits vary depending on your plan.

## Rate limit headers

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.

```python theme={null}
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()
```

<Warning>
  The example above retries indefinitely. In production code, set a maximum retry count to avoid infinite loops if the rate limit persists.
</Warning>

## 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.