Suppression

Suppression is the safety net that stops the BoostMail API from delivering to a recipient who has hard bounced or filed a spam complaint. It is separate from marketing consent, and the difference between the two is the single most misusable part of the API.

Caution

transactional:send is exempt from marketing consent, but it is NOT exempt from suppression. This is the single most misusable property of the API. A transactional message skips the marketing-consent check, but it still will not go to a recipient who has hard bounced or filed a spam complaint.

The transactional check order

For POST /v1/transactional/send, the precedence checks run in this order:

1. erased (redacted recipient)
2. hard_bounce
3. spam_complaint
4. send

Two points in that order are easy to misread.

Erased is not a suppressed receipt. An erased identity is caught earlier, before suppression, and returns 409 conflict (see the Errors guide). It is not a 200 receipt, and there is no reason: "erased".

Only hard_bounce and spam_complaint are suppression. They produce the 200 suppressed receipt:

{
  "status": "suppressed",
  "reason": "hard_bounce"
}

The reason is hard_bounce or spam_complaint. This receipt is how you observe a suppression: there is no separate suppression list to poll. A non-suppressed send returns status: "scheduled" instead (see the Sending guide for the full receipt).

Marketing consent is deliberately not suppression

A subscriber whose marketing status is unsubscribed is deliberately NOT suppressed for transactional send. A transactional message (a receipt, a password reset, an account notice) must still be delivered. Marketing consent gates marketing campaigns, not transactional mail. Suppression, by contrast, applies to both.

Suppression is checked only against a known subscriber. A recipient with no subscriber row has no suppression history, so a transactional message to a fresh or non-subscriber email is simply sent.

Campaign send

Campaign send does NOT run the transactional erased check. The erased case is handled structurally instead: when a shopper is erased, their row is hard-deleted, so they are already absent from the campaign audience. For everyone else, campaign send inherits the internal sending pipeline’s suppression, with no per-recipient receipt. There is no suppressed receipt on a campaign send, so you cannot observe a per-recipient suppression there the way you can on a transactional send (see the Sending guide for the silent-skip behavior on campaign send).