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

# Rate Limits

> Two limits apply to every request: one per IP and one per credential. There is no app-wide quota.

Two independent limits apply, and a request has to pass both: one on the calling IP, one on the credential it presents. For an OAuth app, the app's review status sets the *value* of that per-credential limit — it is not a separate app-wide quota.

| Limit          | Counted against                                                         | Default         |
| -------------- | ----------------------------------------------------------------------- | --------------- |
| Per IP         | The calling IP address                                                  | **1,500 / min** |
| Per credential | An API key                                                              | **500 / min**   |
| Per credential | An OAuth token from an app in `PRODUCTION`                              | **500 / min**   |
| Per credential | An OAuth token from an app in any other status, including `DEVELOPMENT` | **100 / min**   |

Both windows are **60 seconds**.

## The counter is per credential, not per app

The *value* of an OAuth limit comes from the application: `PRODUCTION` gets 500, everything else gets 100. The *counter* does not. Each access token has its own bucket, keyed by the token and the user it belongs to.

Whatever that value is, every token gets all of it. Two users who have each authorized a `PRODUCTION` app get **500 requests per minute each**, not 500 between them — and a thousand users get a thousand separate buckets. Issuing a second token for the same user does the same thing again. A busy integration is never slowed down by a quiet one, and there is no ceiling on an app's total throughput.

## Headers

Every rate-limited response carries all three headers, whether or not the limit was hit:

| Header                  | Value                                                                            |
| ----------------------- | -------------------------------------------------------------------------------- |
| `X-RateLimit-Limit`     | Requests allowed in the current window                                           |
| `X-RateLimit-Remaining` | Requests left in it (never below `0`)                                            |
| `X-RateLimit-Reset`     | **Milliseconds remaining** until the window resets — a duration, not a timestamp |

## When a limit is hit

```json theme={null}
HTTP/1.1 429 Too Many Requests

{"code": 20003, "message": "Too Many Requests"}
```

Read `X-RateLimit-Reset`, wait that many milliseconds, and retry. Nothing is queued on your behalf, and a refused request does not count against the next window.

An IP that has been restricted outright answers `429` with code `200077` instead. That is not a quota — it doesn't clear on its own, so contact support.

## Needing more

Limits can be raised per application without a deploy, for integrations that genuinely need the headroom. Talk to your Lofty contact before building around a higher number — the default is not a hard ceiling, but it isn't lifted automatically either.

<Warning>
  One MCP tool call is not always one request. A [bulk write](/mcp/guides/bulk-writes) of ten records issues ten REST calls against the same bucket, and a tool that pages internally issues one per page. Budget for the requests underneath, not the tool calls above.
</Warning>