API rate limits

API limits are per workspace, per hour, and depend on the workspace's plan. Every token of the workspace shares the one allowance:

• Every request that sends a Bearer token counts, including each request to the MCP server. One MCP tool call is one request.
• The hour is a fixed window, not a rolling one.
• A token that is invalid, revoked or expired is limited to 100 requests an hour.
• The mobile app does not use this allowance. Each login of the app has its own 3,000 requests an hour per workspace, the same on every plan.
• API calls never count toward your event usage.
• When you exceed a limit you get 429 with the error code rate_limited and a Retry-After header: the seconds until the window resets.

Staying under the limits#

• Stats responses are cached on our side and keyed by the site's latest data, so asking for the same thing twice is cheap for us but still counts as a request. Cache on your side too.
• Use one overview request instead of many small ones when you need everything on the Overview.
• Ask for up to 1,000 breakdown rows per request instead of many small pages.
• For bulk data, use exports or the warehouse sync (Business and Enterprise) instead of paging through the API.

Email sending limits#

Operations that send email have their own limits, whether you call them from the app, the API or MCP. Over a limit you get 429 with the code rate_limited and a Retry-After header (seconds), and nothing is sent.

Alert and uptime emails are grouped instead of refused: repeated alerts for one rule become one email to each address every 30 minutes, and a flapping uptime check emails at most 6 status changes an hour.

Other limits#

A few operations make us call another server or do heavy work for you, so they have their own limits. Over a limit you get 429 with the code rate_limited and a Retry-After header.

Imports and exports are limited by how many run at once: 5 imports and 5 exports per workspace, queued or running. One more responds with 422 validation_failed until one finishes.