Zintara bounce.detected webhook: recipient payload and suppression context

Define the decision

The reviewed inbox processing dispatches bounce.detected for a recognized matched bounce path. Its data contains the lead email and leadId. It does not include the original SMTP response, enhanced status code or message body.

Work through the procedure

1. Subscribe the endpoint to bounce.detected.
2. Authenticate the raw request with the webhook signature.
3. Validate the email and leadId fields as data.
4. Make any downstream suppression action idempotent.
5. Preserve the notification and reconcile ambiguous state through a reviewed source of truth.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

{"event":"bounce.detected","data":{"email":"[email protected]","leadId":"00000000-0000-4000-8000-000000000002"},"timestamp":"2026-09-16T10:05:00Z"}

Read the result

The application’s bounce-handling path attempts suppression, but the event should not be treated as an atomic certificate that every downstream system completed its own suppression. Each consumer must verify its action and retain failures.

Check before moving on

1. Do not infer a provider code from the event name.
2. Confirm repeated notifications cannot re-enroll a suppressed contact.

Limits and next action

This event is not an exhaustive stream of every SMTP submission failure. Best-effort dispatch can miss delivery to an endpoint; use reconciliation for workflows requiring stronger completeness.

Source: Zintara product context