The API's own rate limits are not set yet, because the
/api/v1/routes are not built. When they ship, the numbers will be published here and returned in response headers on every request — not only on a rejection. We would rather tell you the limit than have you discover it.
This page documents what is decided so far, and the one limit that is live today.
What will be published when the API ships
Headers on every response, so you can back off before you are rejected rather than after:
X-RateLimit-Limit: 600
X-RateLimit-Remaining: 587
X-RateLimit-Reset: 1770000000X-RateLimit-Limit— requests allowed in the current windowX-RateLimit-Remaining— how many are leftX-RateLimit-Reset— Unix timestamp when the window rolls over
A 429 when you exceed it, with a Retry-After header giving the seconds to
wait. See Errors.
The actual numbers, per plan, on this page. A rate limit you have to discover by hitting it is a rate limit that costs you an outage first.
What is live today: the collector
The collector — where your tracking script sends page views — is rate limited at 600 requests per minute, per site.
That is a flood stop, not a billing meter. It exists to stop a runaway script or a cheap flood, and it sits far above any legitimate single site's steady rate: 600 events a minute is 25 million a month, well past the top of the traffic ladder.
Three things about it:
It is per site, not per organisation. One busy site cannot rate-limit another.
It does not meter your billing. Your monthly event count is counted from stored rows, independently of this limit.
It fails open. If the limiting machinery itself has a problem, requests are allowed through. Losing rate limiting during an incident is recoverable; losing your traffic data is not.
If you ever see a 429 from the collector, see
Events are being dropped.
Writing a client that behaves
Whatever the API's numbers turn out to be, these apply:
Cache. A status page showing yesterday's visitor count does not need to ask every time someone loads it. Cache for a minute and your traffic to us drops by orders of magnitude.
Poll no faster than you need. A live counter refreshing every 10 seconds is 360 requests an hour from one page. Every 60 seconds is 60, and looks identical to a person.
Ask for the small answer. There will be a lightweight overview endpoint alongside the full summary. A status page that needs one number should call the overview, not the summary that fans out across every breakdown.
Handle 429 by backing off. Respect Retry-After, and use exponential
backoff rather than retrying immediately in a loop.