Rate limits

Every surface is metered, and every request — including the rejected ones — is logged.

Authenticated content keys

Two rolling windows, and both must have budget or the request is rejected:

Both are per role: an operator sets one base figure for everybody and overrides the roles that get more. That replaced a pair of environment variables per window — one for members and one for supporters — which hard-wired the tiers to “supporter or not” and could not give a moderator its own number.

The quota is counted against the user, not the individual key, so a second key does not buy a second budget.

Live usage for both windows is shown under Account → API keys, alongside an audit log carrying every request’s method, path, status, address and the item it touched.

List caching and limits

A limit above the ceiling is clamped down rather than refused, so a caller asking for a thousand gets a page and a pagination block that says what it actually got.

Anonymous reads

Per source address, in two windows, both of which must have budget:

The numbers are small on purpose. One address is a household, an office or a carrier NAT, so a generous per-IP budget is a generous budget for a botnet with one node behind each address.

The answer to wanting more is a key — which is free, attributable and revocable, as an address is not.

Headers

Every response carries x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset (plus -day variants) and x-ratelimit-backend. A 429 carries retry-after. Answers are cached for 60 seconds by default and carry x-cache: HIT|MISS.

It degrades rather than refusing

The rule is that an anonymous request which cannot be counted is an unbounded public endpoint. But “cannot be counted in the cache” is not “cannot be counted”:

No cache available

The quota is counted in each app process’s own memory (x-ratelimit-backend: memory). The bound survives; the exactness does not — a deployment running N processes then allows up to N times the budget, and the day window resets on deploy. Requests past it still cost no database query.

No readable source address

Every such request counts against one shared bucket, and the 429 says so. This is a proxy misconfiguration, and it is logged once a minute rather than per request.

Integrations

Two budgets, both enforced, both operator-configurable:

You choose your own per-credential figure at creation (600/minute by default), and it is clamped to the operator’s current ceiling at request time — so lowering the ceiling reins in credentials created under a higher one rather than grandfathering them.

The per-address budget is what bounds a leaked-token farm: somebody holding fifty credentials still only gets one address’s worth of budget.

Over either limit is a 429 for the rest of the minute. Back off; do not retry immediately.

There is also a cap on how many integrations may exist against one content item at a time (10 by default). Revoked ones do not count.

Row budgets are separate

The limits above bound how often you may report. They say nothing about how much each report leaves behind, and for endpoints that append rather than overwrite that is the part that matters — a reporter inside its request budget can still write millions of rows a day.

Those ceilings, and the fact that every one of them degrades rather than refusing, are documented on Reporting server statistics and Integration API — parties.

The app API

Rate limits are per endpoint. The two on the device-login flow are durable — counted in the database rather than only in the cache — because that is the front door, and a cache outage must not turn it into an unmetered row factory.

A token is what a limit is counted against wherever there is one — which is why /apps accepts a bearer despite needing none: the alternative is charging a whole household behind one address as though it were one caller.