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

# Rate Limits

> Understand Thiqwave's rate limiting model and how to handle limits gracefully in your integration.

Thiqwave enforces rate limits to ensure fair usage and platform stability for all partners. Limits are applied **per API key** using a **rolling window** — the window resets continuously rather than at a fixed clock boundary, so your allowance is always calculated against the last 60 seconds and the last 60 minutes respectively.

***

## Rate Limits

All API keys are subject to the following default limits:

| Window     | Limit        |
| ---------- | ------------ |
| Per minute | 300 requests |
| Per second | 10 requests  |

Both limits apply independently. If you exhaust either allowance, subsequent requests are rejected until the window recovers.

If your integration requires higher limits, contact your Thiqwave account manager.

***

## Rate Limit Headers

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

| Header                  | Description                                                        |
| ----------------------- | ------------------------------------------------------------------ |
| `X-RateLimit-Limit`     | The maximum number of requests allowed in the current window       |
| `X-RateLimit-Remaining` | The number of requests you can still make before hitting the limit |
| `X-RateLimit-Reset`     | Unix timestamp (UTC) at which the current window resets            |

Use these headers proactively in your integration to throttle outgoing requests before you hit the limit.

```http theme={null}
HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1744149600
```

***

## Handling 429 Responses

When you exceed a rate limit, the API returns a `429 Too Many Requests` response with a `Retry-After` header:

```http theme={null}
HTTP/1.1 429 Too Many Requests
Retry-After: 14
Content-Type: application/json

{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Please wait before retrying.",
  "code": "RATE_LIMIT_EXCEEDED"
}
```

The `Retry-After` value is the number of seconds you must wait before the API will accept requests from your key again. Your integration must respect this value — sending requests before the window resets will continue to receive `429` responses and will not accelerate the reset.

***

## Best Practices

**Use exponential backoff.** When you receive a `429`, wait the duration specified in `Retry-After`, then retry. If the retry also fails, double the wait time on each subsequent attempt up to a reasonable maximum (e.g. 60 seconds).

```javascript theme={null}
async function requestWithBackoff(fn, maxRetries = 5) {
  let delay = 1000;
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fn();
    } catch (err) {
      if (err.status === 429 && attempt < maxRetries - 1) {
        const retryAfter = err.headers?.["retry-after"];
        const waitMs = retryAfter ? parseInt(retryAfter) * 1000 : delay;
        await new Promise((resolve) => setTimeout(resolve, waitMs));
        delay *= 2;
      } else {
        throw err;
      }
    }
  }
}
```

**Batch requests where possible.** Some Thiqwave endpoints support bulk operations. Where available, use bulk endpoints instead of looping over individual requests — this reduces the total number of API calls you need to make.

**Monitor `X-RateLimit-Remaining` proactively.** If `X-RateLimit-Remaining` drops to a low value, slow down your request rate before you hit zero. This avoids disruption to your integration.

**Use separate API keys per environment.** Staging and production traffic each consume rate limit allowances independently. Using separate keys per environment prevents test traffic from exhausting your production quota.