Event-created records
Bounces, provider suppressions, quarantines, and spam complaints can write suppression records inside the project where they happened.
Suppress an address once. Every send honors it.
NoticeAPI turns hard bounces, spam complaints, provider suppressions, and manual blocks into recipient state your app can see. Future sends fail before provider handoff with recipient_suppressed.
- Event-created records
- Bounces, provider suppressions, quarantines, and spam complaints can write suppression records inside the project where they happened.
- REST list, add, remove
- Audit addresses, add manual blocks, or clear a suppression after support confirms the recipient is safe to contact.
- 409 before handoff
- Suppressed recipients return recipient_suppressed instead of creating provider traffic you already know should stop.
No bypass, no mystery list.
Each suppression is recipient state owned by its project. NoticeAPI enforces it before sending; removal should be a support or re-opt-in decision, not a way around bounces or opt-outs.
A bad outcome should change the next send.
The suppression API keeps that loop visible: provider events create records, send attempts fail fast, and removals stay deliberate.
Event
Bad outcome arrives
Provider bounces, suppressions, quarantines, and spam signals can become suppression records.
Block
Record is visible
Your app can list the project's suppressions or filter by email through /api/v1/suppressions.
409
recipient_suppressed
Future sends fail before provider handoff so the same bad address is not retried.
Review
Unsuppress carefully
Remove a suppression only when the mailbox is fixed or the recipient has clearly asked to receive email again.
How a suppression starts, blocks, and clears.
- 1
Capture the bad outcome
Provider statuses such as Bounced, Suppressed, Quarantined, and FilteredSpam can become suppression records.
- 2
Add manual blocks
Use POST /api/v1/suppressions for support requests, deleted users, or addresses your product should not contact.
- 3
Fail before provider handoff
REST and batch sends return recipient_suppressed with the blocked address instead of retrying the same recipient.
- 4
Remove only after review
DELETE the record only when the mailbox is fixed or the recipient has clearly asked to receive email again.
Controls grouped by the failure they prevent.
REST list, add, remove
Audit addresses, add manual blocks, or clear a suppression after support confirms the recipient is safe to contact.
409 before handoff
Suppressed recipients return recipient_suppressed instead of creating provider traffic you already know should stop.
Broadcasts skip bad recipients
Broadcast fan-out checks suppressions per contact; unsubscribed contacts stay out through audience state.
Questions before you ship.
Can I bypass a suppression for a transactional send?
No. Suppressions are enforced before provider handoff. Remove the record only after a real mailbox fix, support review, or recipient request.
What creates an automatic suppression?
Provider delivery statuses such as Bounced, Suppressed, Quarantined, and FilteredSpam can create suppression records. Manual API blocks are stored as manual records.
Are simulated bounces suppressed?
No. Simulator bounces are repeatable test outcomes and do not suppress the simulator address.
When should I remove a suppression?
Only when you have a clear reason, such as a recipient fixing their mailbox or asking to receive email again.
Read the implementation.
Test it. Then send for real.
Simulator outcomes are free. Move to a verified domain when the path is ready.