Fail-open & the verdict model

Two ideas underpin how Detent behaves at the edges: what happens when things go wrong on our side, and what a normal response actually means.

Fail-open

If Detent’s infrastructure is ever briefly unavailable, /v1/limit doesn’t fail your request — it allows it, and we alert ourselves internally. The reasoning is simple: a rate limiter that goes down and starts blocking everything turns a small outage on our end into a big outage on yours. We’d rather risk under-limiting for a few seconds than take your app down with us.

The verdict model

/v1/limit returns HTTP 200 for every verdict, including { "allowed": false }. A 200 doesn’t mean “allowed” — it means “here’s the decision.” 4xx status codes are reserved for problems with the request itself, not with the rate-limit outcome:

• 400 — malformed request (invalid_request)
• 401 — missing or invalid API key
• 403 — algorithm not available on your plan (algorithm_not_on_plan)
• 404 — no rule configured for that namespace (key_not_found)

Two policy gates sit in front of the verdict and can short-circuit it with a non-200 status: 402 when billing isn’t in good standing, and 429 with code monthly_hard_cap when you’ve crossed the anti-abuse ceiling. Outside of those two gates, Detent never emits a 429 on its own — you are the one who translates allowed: false into whatever response code makes sense for your users.