API Rate Limits

Every request to the Discovery API is counted against a rate limit. This document explains what the limits are, which API version you have to be on to get the higher ones, how to tell how much budget you have left, and what to do when you run out.

Overview

Rate limits used to be simple and low: 60 requests per minute per user, on every version of the API.

The latest API version raises that substantially. If you are calling the latest version, you now get:

• 1,000 requests per minute per user, and
• 1,000 requests per minute per tenant, shared by everyone in your organization.

Both limits are enforced at the same time. Older API versions are unchanged at 60 requests per minute.

Limits by API version

To get the higher limit you must call the latest (2026-07-01) version. Pointing an existing integration at /api/2026-07-01/...   instead of /api/v1/...   or /api/beta/...   is the entire upgrade as far as rate limiting is concerned — there is nothing to request or enable.

How the 1,000 is shared

On the latest version, two counters run at once — yours and your organization's — and a request is refused as soon as either is full. Because both ceilings are 1,000, one integration can spend the organization's entire budget, or several can share it. Nothing reserves a share for anyone: whoever spends it first has it.

There is no per-token budget. Counters are keyed to the user who owns the token, so a second token for the same user adds no capacity. To give integrations separate counters, give them separate users.

Exceptions

Still limited to 60/min per IP, because no token means no user or tenant to budget for:

• Signed download URLs — report CSVs, invoice PDFs, document downloads.
• Any unauthenticated request.

The MCP surface used by AI clients has its own separate 60/min limit.

Handling limits in your client

Every response carries X-RateLimit-Limit   and X-RateLimit-Remaining  . When both counters are in play, these report whichever has the least room left — so X-RateLimit-Remaining   is always what you can actually still spend.

Exceeding a limit returns 429 Too Many Requests with a Retry-After   header.

• Treat 429 as retriable: sleep for Retry-After   seconds, then retry. Windows reset 60 seconds after a counter's first request, not at the top of each clock minute, so read Retry-After   rather than waiting for :00  .

Requests are counted, not weighed

Every request costs exactly one, however much data it returns. So the cheapest thing you can do is ask for more per request:

• Use ?include=   to pull related data in one call, instead of fetching a list and then making one request per row. That N+1 pattern is what actually exhausts a 1,000/minute budget.
• Raise ?per_page=   when paginating. The current version defaults to 15 and allows up to 200, turning a 3,000-record export from 200 requests into 15.

Heavy requests are still slower to serve and receive — they just don't cost extra against the limit.

If you have additional questions or need more in depth information, please feel free to send us a message using the help beacon in the lower right-hand corner.