Deny or admit identifiers before any rule runs.
IP and key block/allow lists evaluated ahead of rate rules. A blocked identifier never consumes capacity; an allowed one never gets denied.
Deny or admit identifiers before any rule runs.
Some identifiers should never be evaluated against a rule. A known attacker should be denied without consuming a single counter. A trusted internal service should never be throttled, no matter what the window says. Block and allow lists handle both, ahead of every rule.
A blocklist entry binds an identifier to an action — block or allow — with an optional note. Entries are evaluated inside the same atomic Lua script as the rule, before any capacity is consumed:
| Field | Values | Meaning |
|---|---|---|
identifier_type | ip · key · user | What the entry matches |
value | string | The exact identifier to match |
action | block · allow | Deny or admit |
note | string, optional | Free-text context for your team |
GET /v1/ratelimit/blocklist — list entriesPOST /v1/ratelimit/blocklist — createDELETE /v1/ratelimit/blocklist/:id — removeEntries require the manage_project scope and count against your tier's blocklist cap; exceeding it rejects new entries with PLAN_LIMIT (rate_limit_blocklist_cap_reached).