Rate limits

KINDI enforces a per-key rate limit on the masking endpoints.

Per-key limits

Each API key has a rate_limit_rpm field set when the key is minted (max 100,000). The defaults depend on how the caller is identified:

Caller	Limit
A normal API key (`mk_live_…`)	60 requests / minute unless you set `rate_limit_rpm` when minting it
A playground key	30 requests / minute by default (playground keys are minted from the dashboard Keys page and skip billing)
A dashboard session (browser cookie)	60 requests / minute, counted per user rather than per key, since a session has no key to attribute the request to

/api/v1/mask and /api/v1/redact check this budget on every call.

It's a sliding window, not a clock minute

The limiter keeps a rolling 60-second window of your recent request timestamps, not a fixed HH:MM bucket. A request is rejected when the number of requests in the last 60 seconds exceeds the limit. (A fixed bucket would let a caller land two full bursts either side of a minute boundary and get double the nominal rate; the sliding window closes that.)

When a request would exceed the budget, the server returns:

12345HTTP/1.1 429 Too Many Requests
Retry-After: 17
Content-Type: application/json

{"detail":"Rate limit exceeded"}

Retry-After is 60 − the age of the oldest request still inside the window: the number of seconds until one slot ages out and frees up. Sleep for it and retry.

Retry-After is the only rate-limit header KINDI sends. There is no X-RateLimit-Limit / -Remaining / -Reset family; don't write client code that reads them, and don't infer your remaining budget from headers. Track it client-side, or just handle the 429.

Rate-limiter outages are fail-open: if the limiter is briefly unreachable, the request is allowed and a warning is logged server-side.