Which delivery events does else.events forward?

Delivered, soft bounce, hard bounce, failed (provider error), opened and clicked — normalised from whatever your configured provider reports.

How do I link a delivery webhook back to my domain event?

Each webhook payload includes the original event type (e.g. user.password_reset_requested) and the user identifier, so you can correlate delivery status with the triggering action in your system.

Can I filter which event types trigger webhooks?

Yes. The webhook configuration lets you select which delivery statuses (delivered, bounced, failed, etc.) you want forwarded to your endpoint.

Is the webhook payload signed?

Yes. Webhook requests include a signature header you can verify against your webhook secret to confirm the payload is genuine.

Know what happened to every transactional email you sent

Delivery receipts, bounce notifications, open and click events — forwarded to your webhook endpoint so your app always knows the state of every email.

Set up email webhooks See email logs for SaaS

Why raw provider webhooks are painful to work with

Every provider has a different webhook schema

Postmark, Mailgun, SendGrid — each fires different event types with different field names. Custom parsing code per provider.

No link between delivery event and your domain event

A "delivered" notification from Postmark tells you the message ID — not which user.password_reset_requested event triggered it.

Provider switching breaks your webhook handlers

Migrate from Postmark to SendGrid and all your webhook parsing logic needs to be rewritten.

Missed bounces damage sender reputation

Without reliable bounce handling, invalid addresses accumulate and hurt deliverability for all your emails.

Normalised delivery events, linked to your domain events

Unified webhook schema across providers

else.events normalises delivery events from every provider into a consistent schema — delivered, bounced, failed, opened, clicked.

Event correlation out of the box

Each delivery webhook includes the original event type and user reference, so your system knows which domain event triggered the email.

Provider-agnostic

Switch email providers without changing your webhook handler. The else.events schema stays the same.

Configurable per workspace

Set your webhook endpoint once. All delivery events for all email types flow to the same endpoint.

Frequently asked questions

Which delivery events does else.events forward?: Delivered, soft bounce, hard bounce, failed (provider error), opened and clicked — normalised from whatever your configured provider reports.
How do I link a delivery webhook back to my domain event?: Each webhook payload includes the original event type (e.g. user.password_reset_requested) and the user identifier, so you can correlate delivery status with the triggering action in your system.
Can I filter which event types trigger webhooks?: Yes. The webhook configuration lets you select which delivery statuses (delivered, bounced, failed, etc.) you want forwarded to your endpoint.
Is the webhook payload signed?: Yes. Webhook requests include a signature header you can verify against your webhook secret to confirm the payload is genuine.

Close the loop on every transactional email

Unified delivery webhooks, linked to your domain events, provider-agnostic.

Free during public beta
Normalised schema across providers
Correlates with your domain events