Rate limits and quotas

Rate limits keep one integration from slowing down everyone else. They are counted per credential on the Management API and per site, visitor or customer on the public APIs. Quotas are a different thing: they cap how much a site can store, such as collection items or webhook endpoints, and depend on the plan.

When you hit a limit

The API returns 429 with code RATE_LIMITED and a Retry-After header in seconds. Wait at least that long, then retry with backoff.

{
  "error": {
    "code": "RATE_LIMITED",
    "message": "Too many requests.",
    "details": { "retryAfter": 12 }
  }
}

Some operations return 429 with a more specific code when the backend is busy rather than when you sent too much, for example SEARCH_BUSY or ANALYTICS_BUSY. Handle them the same way.

Management API

Each token has its own budget. Most operations share the default tier. Analytics queries are heavier, so they have a lower tier per token and a cap per site that every token on that site shares. REST and MCP calls count against the same budgets.

Each operation in the Management API reference shows its tier, and the OpenAPI document carries it as x-kanorio-rate-limit.

Content Delivery API

Responses served from the edge cache are not counted, so a busy site with a warm cache never hits these limits. Cache misses, form writes, analytics beacons and draft previews are counted in token buckets: each bucket refills at a steady rate and allows a short burst. Counted responses carry these headers:

Build pages on your server or at build time where you can, and let the edge cache absorb visitor traffic.

Customer API

Signed-in calls are limited per customer token. Sign-in requests are limited per IP address.

Limits and quotas today

The values below are generated from the same constants the APIs enforce.

Management API tiers

Content Delivery API buckets

Cache hits are not counted. Only requests that miss the edge cache, form writes and analytics beacons use these buckets.

Customer API buckets

Plan quotas