> For the complete documentation index, see [llms.txt](https://docs.insurgrid.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.insurgrid.com/guides/rate-limits.md).

# Rate limits

InsurGrid limits how many API calls your account can make in a given window, to keep the API fast and fair for everyone. This guide covers how limits are communicated and how to back off cleanly when you hit one.

Limits are applied **per account**, across all your API tokens combined.

> Exact limits (requests per window) aren't printed here — they're shared with you during onboarding and can vary by account. Design your integration to handle `429` gracefully rather than hard-coding a number.

## When you're over the limit

A request over your limit returns `429 Too Many Requests` with the standard [error envelope](/guides/errors.md), plus these headers:

| Header                  | Meaning                                   |
| ----------------------- | ----------------------------------------- |
| `Retry-After`           | Seconds to wait before your next request. |
| `X-RateLimit-Limit`     | The ceiling for the current window.       |
| `X-RateLimit-Remaining` | Calls left in the current window.         |
| `X-RateLimit-Reset`     | When the window resets, as epoch seconds. |

> **New term — epoch seconds:** the number of seconds since January 1, 1970 UTC — a common way to represent a timestamp as a plain number. `new Date(epoch * 1000)` (Node) or `datetime.fromtimestamp(epoch)` (Python) converts it to a normal date.

## Back off using `Retry-After`

Don't retry immediately. Wait at least `Retry-After` seconds, then try again. A minimal retry wrapper:

**Node:**

```js
// client.js
async function callWithBackoff(url, options, maxAttempts = 5) {
  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
    const res = await fetch(url, options);

    if (res.status !== 429) return res;

    const retryAfter = Number(res.headers.get("Retry-After") ?? "1");
    console.warn(`Rate limited. Waiting ${retryAfter}s (attempt ${attempt}/${maxAttempts})`);
    await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000));
  }
  throw new Error("Exceeded max retry attempts after repeated 429s");
}
```

**Python:**

```python
# client.py
import time
import requests

def call_with_backoff(url, headers=None, max_attempts=5):
    for attempt in range(1, max_attempts + 1):
        resp = requests.get(url, headers=headers)

        if resp.status_code != 429:
            return resp

        retry_after = int(resp.headers.get("Retry-After", "1"))
        print(f"Rate limited. Waiting {retry_after}s (attempt {attempt}/{max_attempts})")
        time.sleep(retry_after)

    raise RuntimeError("Exceeded max retry attempts after repeated 429s")
```

## Tips

* Check `X-RateLimit-Remaining` proactively on high-volume jobs — like a full [pagination](/guides/pagination.md) sweep — and slow down before you hit `0`, rather than waiting for a `429`.
* If you're consistently hitting your limit, contact InsurGrid — limits can be raised for legitimate high-volume use.

## Related

* [Errors & status codes](/guides/errors.md)
* [Pagination (cursors)](/guides/pagination.md)
* Support


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.insurgrid.com/guides/rate-limits.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.