Concurrency & leases

concurrent_limit limits how much work is in flight at once, not how many requests happen per window. That’s a different shape of problem than the other algorithms solve, so it isn’t a single /v1/limit call — it’s lease-based. You acquire a lease before doing the work, then release it when you’re done.

# acquire
curl -X POST https://api.detent.fr/v1/leases \
  -H "Authorization: Bearer dt_live_…" \
  -d '{"namespace":"checkout","key":"user_42","limit":5,"window_ms":300000}'
# → { "allowed": true, "lease_id": "…", "active": 1, "limit": 5, "reset_ms": 300000 }

# release
curl -X DELETE https://api.detent.fr/v1/leases/LEASE_ID \
  -H "Authorization: Bearer dt_live_…"

limit is the maximum number of concurrent leases allowed per key. window_ms is the lease’s TTL — if you never call DELETE, the lease is auto-released once the TTL passes, so a crashed client can’t leak a slot forever. Both limit and window_ms are optional if the namespace already has a concurrent_limit rule configured.

When you’re at capacity, the response is { "allowed": false } with no lease_id — there’s nothing to release because nothing was acquired. Treat that the same way you’d treat a denied /v1/limit verdict: it’s data, and your app decides what to do with it (reject, queue, retry).

concurrent_limit and the leases API are available on Pro and Scale plans.