Forward Plunk system events through workflow webhooks

Plunk documents webhooks as a workflow capability: an event triggers a workflow, whose Webhook step forwards data to your endpoint. Do not assume this is an account-wide webhook subscription API identical to another ESP’s.

Build an authenticated event workflow

1. Select a system event such as email.bounce, email.delivery, or email.complaint as the workflow trigger.
2. Add a Webhook step with a fixed HTTPS target and explicit method.
3. Configure the documented custom-header authentication and verify it at your receiver. Keep secrets out of logged workflow payloads.
4. Choose the default payload or deliberately map a custom body; a custom body replaces the default rather than merely adding fields.

The workflow webhook guide distinguishes system events from manually tracked custom events. A public tracking request claiming an event name must not impersonate a provider-generated delivery outcome.

Test state and recovery

Trigger controlled test activity, confirm the workflow selected the intended event, and verify authentication and durable receiver persistence. Deduplicate effects and inspect workflow delivery failures under the current retry contract.

Keep bounce/complaint protections against late or duplicated updates. Inbound email.received requires separate receiving setup; a webhook step alone does not point domain MX at Plunk or provide a reply mailbox.

If connecting to an application that also handles MailKite, retain separate authentication and identifier namespaces. Plunk’s workflow payload does not carry a MailKite signature.