The API is live and is not rate limited yet. The endpoints ship without a per-key limit; the collector's limit below is a separate thing and has been live all along.
When the API's limit arrives, 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. Until then, the section below describes what will be sent, and nothing in it is enforced.
This page documents what is decided, and the one limit that is live today.
What will be published when the limit arrives
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.
None of the three headers is sent today. A client that reads them should treat their absence as "no limit known" rather than as zero remaining.
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.