<Intro>

<EndpointHeader />

<Description>

Returns one suppression record: the address, why it is suppressed (`reason`), how the record came to exist (`origin`), and which message categories it blocks (`applies_to`). To find a record when you only know the address, use GET /v1/email/suppressions with the `email` parameter. An ID that does not exist in the workspace returns `404`.

</Description>

</Intro>

<Payload kind="response">

<Field name="id" type="string" required />

<Field name="email" type="string" required>

<Description>

The suppressed address, stored lowercase.

</Description>

</Field>

<Field name="scope" type="object" required>

<FieldChildren kind="response">

<Field name="type" type="string" prefix="scope." required>

<Description>

The scope this suppression applies to. Suppressions are currently workspace-scoped; the other scope types are reserved for future use.

</Description>

<Description>

Possible values: `workspace`, `category`, `audience`, `topic`, `contact`, `domain`

</Description>

</Field>

<Field name="id" type="string" prefix="scope." required>

<Description>

Public ID or alias of the scoped resource. For workspace scope, this is the workspace ID (`ws_`-prefixed).

</Description>

</Field>

</FieldChildren>

</Field>

<Field name="reason" type="string" required>

<Description>

Why the address is suppressed: `hard_bounce` (a delivery permanently failed), `complaint` (the recipient reported a message as spam), `unsubscribe` (the recipient opted out), or `manual` (added through the API or dashboard). An address can hold one record per reason. This list grows over time; treat unknown values as informational rather than rejecting the record.

</Description>

<Description>

Possible values (may grow over time): `hard_bounce`, `complaint`, `unsubscribe`, `manual`

</Description>

</Field>

<Field name="origin" type="string" required>

<Description>

How the suppression came to exist: `bounce_event` (created automatically from a hard bounce), `complaint_event` (from a spam complaint), `unsubscribe_event` (from an unsubscribe reported for a message, such as the recipient's mail client's unsubscribe action), `unsubscribe_link` (the recipient opted out through the unsubscribe page linked from a message), `api_key` (added through the API with an API key), or `user` (added by a user in the dashboard). This list grows over time; treat unknown values as informational rather than rejecting the record.

</Description>

<Description>

Possible values (may grow over time): `bounce_event`, `complaint_event`, `unsubscribe_event`, `unsubscribe_link`, `api_key`, `user`

</Description>

</Field>

<Field name="applies_to" type="string" required>

<Description>

Which sends the suppression blocks. `all` blocks every message category, including transactional. `non_transactional` blocks marketing and future non-transactional categories but allows transactional, so a recipient who complained or unsubscribed can still receive mail like password resets. `category` is reserved for category-specific preferences. This list grows over time; treat an unknown value as blocking at least non-transactional mail.

</Description>

<Description>

Possible values (may grow over time): `all`, `non_transactional`, `category`

</Description>

</Field>

<Field name="source_email_id" type="nullable string">

<Description>

ID of the email that triggered suppression. Null for manual additions.

</Description>

</Field>

<Field name="source_recipient_id" type="nullable string">

<Description>

ID of the recipient event that triggered suppression. Null for manual additions.

</Description>

</Field>

<Field name="created_at" type="string" required>

<Description>

When the address was suppressed.

</Description>

</Field>

</Payload>