API rate limits

API requests per hour for each Privatus Analytics plan, what a 429 rate_limited response means, and practical ways to stay under the limits with caching.

# API rate limits

> API requests per hour for each Privatus Analytics plan, what a 429 rate_limited response means, and practical ways to stay under the limits with caching.

API limits are per API token, per hour, and depend on the workspace's plan:

| Plan | Requests / hour |
|---|---|
| Free | 1,000 |
| Pro | 5,000 |
| Business | 20,000 |
| Enterprise | Custom |

- API calls **never count** toward your event usage.
- When you exceed a limit you get `429` with the error code
  `rate_limited`. Wait and retry with exponential backoff.

## 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](/docs/reports/exports) or the warehouse
  sync instead of paging through the API.

The [ingest API](/docs/server-side) has its own per-key limits and isn't
counted here.

## 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.

| What | Limit |
|---|---|
| Team invitations | 20 per member an hour, 50 per workspace a day |
| Report recipient invites | 30 new invites per member an hour, 100 per workspace a day, 3 a week to one address from all workspaces |
| Report and channel tests | 10 per member an hour, 30 per workspace an hour |
| Site transfers | 20 per workspace a day |
| Any of these to one address | 10 a day per workspace |

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

以 Markdown 檢視

API limits are per API token, per hour, and depend on the workspace's plan:

Plan	Requests / hour
Free	1,000
Pro	5,000
Business	20,000
Enterprise	Custom

API calls never count toward your event usage.
When you exceed a limit you get 429 with the error code rate_limited. Wait and retry with exponential backoff.

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 instead of paging through the API.

The ingest API has its own per-key limits and isn't counted here.

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.

What	Limit
Team invitations	20 per member an hour, 50 per workspace a day
Report recipient invites	30 new invites per member an hour, 100 per workspace a day, 3 a week to one address from all workspaces
Report and channel tests	10 per member an hour, 30 per workspace an hour
Site transfers	20 per workspace a day
Any of these to one address	10 a day per workspace

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