What does suppressed_recipient mean?

suppressed_recipient means every recipient of this send is on a suppression list, and the send was refused. GET /suppressions names the row and why it exists; DELETE /suppressions/{id} clears a hard bounce you have fixed; an unsubscribe or a spam complaint is a person's to lift, in the console. The error catalogue message is "Recipient is on the account suppression list.", and retryable stays false while the row exists.

When the code answers, and when it does not

The send path checks every address in to, cc and bcc against the account's rows. The refusal comes only when none is left, and the message on the wire then reads "Every recipient of this email is on a suppression list. Remove them via DELETE /suppressions/:id and retry." When at least one recipient is clear, the send is accepted, the suppressed addresses are dropped from it, and one email.suppressed event is recorded per dropped address with email, level and origin, so GET /emails/{id}/events shows who did not get it. The same code answers when every recipient failed pre-send verification, and the message says so.

POST /emails/preflight runs the same check without sending. Its checks.suppression lists kept and suppressed, and when nobody is left ok is false and error carries this code. The address suppressed@simulator.agentisend.com on the simulator produces the accepted-then-suppressed path without touching your list.

Reading the row

GET /suppressions returns email, level and origin per row. Its summary is "Every suppressed address or domain for this account (global platform rows included)." level is address, domain or global; a domain row is written as @example.com and matches every address under it. origin is bounce, complaint or manual, and says how the row got there. Over MCP the same list is list_suppressions.

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"
}

Clearing it, and what not to do

The catalogue fix says "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." The DELETE /suppressions/{id} summary matches: "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." A key that tries anyway is answered human_action_required, and that message reads "This address asked not to be contacted — it unsubscribed or reported a message as spam. An API key cannot lift that." Both calls are management endpoints, so a sending_access key is answered restricted_api_key.

retryable is false, so do not retry the send: the row is still there. Do not route around the list with a different From or another key; the list is the account's, and it holds addresses that bounced hard or asked to stop hearing from you. Deliverability says hard bounces and complaints add the recipient to the list, and sending to them again is what the list prevents. When the bounce was the address's fault and you have the corrected one, clear the row with DELETE /suppressions/{id} and send to the corrected address.

Next

• Deliverability
• Email for AI agents
• How do I remove an address from the suppression list?
• Why did my email bounce?