Questions · Updated 2026-09-28
How do I remove an address from the suppression list?
Remove an address from the suppression list with DELETE /suppressions/{id}, using the row id from GET /suppressions, or lift many at once with POST /suppressions/batch/remove. A hard bounce you have fixed can be cleared with an API key; an unsubscribe or a spam complaint is a person’s to lift, in the console.
Remove an address from the suppression list with DELETE /suppressions/{id}. Find the row's id with GET /suppressions, which lists every row with email, level, origin and created_at. The operation summary says: "Remove one suppression row. A hard bounce you have fixed can be cleared with an API key; an unsubscribe or a spam complaint is a person’s to lift, in the console." To lift several at once, send the addresses to POST /suppressions/batch/remove.
Read the row first
level is address, domain or global. origin is bounce, complaint or manual. Deliverability says hard bounces and complaints add the recipient automatically; an unsubscribe is recorded as a manual row scoped to marketing mail, and a row you add yourself with POST /suppressions is manual too. A global row is a platform row: the GET /suppressions summary says the list includes "global platform rows", and the account cannot remove one. The events are suppression.added and suppression.removed; an address the list drops from a send is recorded as an email.suppressed event, and a scheduled message the list stops at send time ends with status suppressed.
What a key can lift
A key calling DELETE /suppressions/{id} on a bounce row gets deleted: true. On a complaint row, or on the manual row an unsubscribe wrote, the call is refused with human_action_required, and on this route the message is "This address asked not to be contacted — it unsubscribed or reported a message as spam. An API key cannot lift that." That address said no; the fix sends the decision to a person, in the console under Suppressions, if the row was recorded in error.
curl -sS -X DELETE https://api.agentisend.com/suppressions/9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42 \
-H "Authorization: Bearer $AGENTISEND_API_KEY" \
-H "Idempotency-Key: $(uuidgen)"200
{
"deleted": true,
"id": "9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42"
}Several at once
POST /suppressions/batch/remove takes emails and an optional level. Its summary: "Lift up to 500 suppressions by address. An address that was not suppressed reads not_found, not an error." Each row of data carries email, index and a status of removed, not_found or rejected, with error on a rejected row, so one address a key cannot lift does not stop the rest.
The refusal that sent you here
A send to a suppressed address is refused with suppressed_recipient. The catalogue message is "Recipient is on the account suppression list." and the fix is "GET /suppressions says which address and why. A hard bounce you have fixed can be cleared with DELETE /suppressions/:id; an unsubscribe or a spam complaint cannot — that address asked not to be contacted." retryable is false, so do not retry the send; clear the row or change the recipient. To add a row, POST /suppressions with email, or @example.com to suppress a whole domain.