Skip to main content
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. 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:

​
When a limit is hit

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.
One MCP tool call is not always one request. A bulk write 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.