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

# Authmatech API Rate Limits & 429 Handling

> How Authmatech rate limits API requests per client, what a 429 response means, and how to handle it with exponential backoff and jitter.

Authmatech applies request limits **per client** to keep the platform fast and fair for everyone. Limits are generous and most integrations never approach them.

## The limit

Each account has a per-client request budget, **1,000 requests per minute by default**. The budget covers all `/v1/api/**` calls made with your `X-API-KEY` / `X-CLIENT-ID`.

<Note>
  Need more headroom for a launch, a migration, or sustained high volume? Contact [connect@authmatech.com](mailto:connect@authmatech.com) to raise your per-client limit.
</Note>

## When you exceed it

If you exceed your budget, the API returns `429 Too Many Requests` in the standard envelope:

```json theme={null}
{
  "success": false,
  "messages": [
    { "type": "FAILURE", "message": "Rate limit exceeded.", "httpStatus": "TOO_MANY_REQUESTS" }
  ],
  "data": null
}
```

Requests are **not** queued or retried for you — your client owns the retry logic.

## Handling 429 with backoff

Retry `429` (and `500`) with **exponential backoff and jitter**:

```javascript theme={null}
async function withBackoff(fn, { maxAttempts = 5 } = {}) {
  let attempt = 0;
  while (true) {
    const res = await fn();
    if (res.status !== 429 && res.status < 500) return res;
    if (++attempt >= maxAttempts) return res;
    const base = Math.min(60_000, 1000 * 2 ** (attempt - 1)); // 1s,2s,4s… cap 60s
    const jitter = Math.floor(Math.random() * 200) - 100;     // ±100ms
    await new Promise(r => setTimeout(r, base + jitter));
  }
}
```

1. Wait \~1 s after the first `429`.
2. Double the wait each attempt: 2 s → 4 s → 8 s …
3. Cap attempts (e.g. 5) and the maximum wait (e.g. 60 s).
4. Add ±100 ms jitter so multiple clients don't retry in lockstep.

## Staying under the limit

* **Batch where you can** and avoid tight polling loops — use the smallest reasonable poll interval for portal/analytics endpoints.
* **Cache** responses that don't change between calls.
* **Spread** bulk work (e.g. large verification batches) over time rather than firing everything at once.

## Related

<CardGroup cols={2}>
  <Card title="Errors & responses" icon="triangle-exclamation" href="/api/errors">
    Every status code and the response envelope.
  </Card>

  <Card title="Testing & environments" icon="flask" href="/guides/testing">
    Build and validate before you scale up.
  </Card>
</CardGroup>