Allow and block lists

Decide specific users, email addresses, domains, IP addresses or devices outright, for one benefit or all of them.

Allow and block lists decide specific claims outright. An allow list entry allows every claim it matches. A block list entry denies every claim it matches. Your policy doesn't need to change.

Why it matters

Some decisions are already made before a claim arrives. A partner's team should always get its trial. Your QA accounts should never be blocked. A domain behind a wave of repeat claims should be stopped today, not after a policy review. Lists handle these cases in seconds, with a reason your team can read later.

Key capabilities

Final for matching claims. A matching entry decides the claim, whatever the policy says. If a claim matches both an allow and a block entry, the block entry wins.
Immediate effect. Entries apply to new evaluations as soon as they are saved.
Consistent matching. Each value is matched exactly as AbuseZero matches identifiers during an evaluation, so an entry catches the claims it's meant to catch.
Expiry. An entry can expire at an exact time or after a set number of days, measured on AbuseZero's clock. Expired entries stop matching on their own.
Bulk changes. Add up to 50 values in one request. Every value gets its own result, and one bad value never blocks the rest.
Audit trail. Every entry carries a reason, and every change is recorded in your audit log.

Configuration

Field	Values
`kind`	`allow` or `block`.
`type`	What the value is. See the table below.
`value` or `values`	One value, or up to 50 values. Each is up to 254 characters.
`benefit_id`	A `ben_` ID to limit the entry to one benefit, or `null` for every benefit.
`reason`	Why the entry exists, 3 to 500 characters.
`expires_at` or `expires_in_days`	An exact expiry time, or 1 to 3,650 days from now. Send one or neither. Without either, the entry never expires.

Type	Matches
`email`	The email address, including variations that reach the same mailbox.
`email_exact`	Only this exact email address.
`domain`	Every email address at the domain, such as `example.com`.
`ip`	One IP address.
`user`	Your user ID, as sent in `subject.external_id`.
`device_id`	Your device ID, as sent in `identifiers.device_id`.

Block a domain for 30 days

{
  "kind": "block",
  "type": "domain",
  "value": "example.net",
  "benefit_id": null,
  "reason": "Repeat trial claims traced to this domain",
  "expires_in_days": 30
}

Allow your QA team on one benefit

{
  "kind": "allow",
  "type": "email_exact",
  "values": ["qa1@example.com", "qa2@example.com", "not-an-email"],
  "benefit_id": "ben_8c2f1d64-3a7e-4b19-9f05-2e6d7c1a9b38",
  "reason": "Internal QA accounts"
}

Programmatic access

Interface	Use
AbuseZero REST API	`POST /v1/access-lists`, `GET /v1/access-lists`, `GET /v1/access-lists/{id}`, `DELETE /v1/access-lists/{id}`
AbuseZero Node.js SDK	`addAccessListEntry()`, `addAccessListEntries()`, `accessLists()`, `deleteAccessListEntry()`
AbuseZero CLI	`abusezero access-lists add`, `list`, `get`, `delete`
AbuseZero MCP server	`abusezero_add_access_list_entry`, `abusezero_list_access_lists`, `abusezero_get_access_list_entry`, `abusezero_delete_access_list_entry`
Dashboard	Policies → Allow & block lists

Response data

A single value returns the saved entry's ID. A batch returns a result for each value:

{
  "object": "list",
  "data": [
    { "object": "access_list_result", "value": "qa1@example.com", "status": "created", "id": "lst_2b7d9e41-6a3c-4f85-9e17-c0d4a8b52f63" },
    { "object": "access_list_result", "value": "qa2@example.com", "status": "already_listed", "id": "lst_7f1a3c58-2e9b-4d06-b84a-5c9e1d7f2a30" },
    { "object": "access_list_result", "value": "not-an-email", "status": "invalid", "reason": "Use an email such as name@example.com. Quoted and international local parts are not supported." }
  ]
}

already_listed means an active entry with the same kind, type, value and benefit already exists. Its ID is returned, and nothing is duplicated.

Each entry looks like this:

{
  "object": "access_list_entry",
  "id": "lst_2b7d9e41-6a3c-4f85-9e17-c0d4a8b52f63",
  "kind": "allow",
  "type": "email_exact",
  "benefit": "ben_8c2f1d64-3a7e-4b19-9f05-2e6d7c1a9b38",
  "reason": "Internal QA accounts",
  "expires_at": null,
  "created_at": "2026-10-28T11:20:45.000Z"
}

The API doesn't return an entry's value, so put the context your team needs in reason.