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

# API Rate Limits

> DevTune REST API per-key rate limits by Plus, Pro, and Enterprise plan tiers, including request quotas, throttling behavior, and 429 response handling.

The DevTune API enforces per-key rate limits to ensure fair usage. Limits are based on your subscription plan tier.

## Limits by Plan

| Plan       | Requests per Minute |
| ---------- | ------------------- |
| Plus       | 100                 |
| Pro        | 500                 |
| Enterprise | 1,000               |

Rate limits are applied per API key, not per account. If you have multiple keys, each has its own independent limit.

## Rate Limit Headers

Every API response includes headers that tell you your current rate limit status:

| Header                  | Description                                     |
| ----------------------- | ----------------------------------------------- |
| `X-RateLimit-Limit`     | Maximum requests allowed per window             |
| `X-RateLimit-Remaining` | Requests remaining in the current window        |
| `X-RateLimit-Reset`     | Unix timestamp (seconds) when the window resets |

### Example Response Headers

```
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1707400800
```

## When You Exceed the Limit

If you exceed your rate limit, the API returns a `429 Too Many Requests` response:

```json theme={null}
{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded. Please try again later.",
  "status": 429
}
```

The response includes rate limit headers so you know when to retry.

## Best Practices

* **Check the headers** before making rapid requests. Use `X-RateLimit-Remaining` to pace your calls.
* **Use exponential backoff** when you receive a 429. Wait until the `X-RateLimit-Reset` timestamp before retrying.
* **Cache responses** where possible. Most DevTune data updates once per day (after scheduled tracking runs), so caching for several minutes is usually appropriate.
* **Batch your reads** rather than polling frequently. Pull data once and process it locally.

## Related Documentation

* **[Authentication](/api-reference/authentication)** - API key setup
* **[Error Handling](/api-reference/errors)** - All error responses