Webhooks let an email provider push delivery and bounce events to your application the moment they happen, instead of you having to check a dashboard or poll an API to find out. That distinction matters more than it sounds like it should: without webhooks, "did this email actually get delivered" is a question you have to go looking for the answer to; with them, it's something your application already knows and can react to automatically — flagging a bounced address, marking a signup as verified, or alerting a user that a notification failed to reach them. Notify is used as the running example throughout this piece, since it pairs webhooks directly with the delivery logs described below, but the underlying mechanics apply to any provider offering webhook-based event tracking.
What "Delivery" and "Bounce" Events Actually Mean
Before getting into webhooks specifically, it helps to be precise about what's being tracked. A transactional email typically moves through a few distinct states after you send it:
- Accepted/Sent — the provider has received your send request and queued it.
- Delivered — the receiving mail server has accepted the message.
-
Bounced — the message wasn't delivered. This splits into two meaningfully different cases:
- Hard bounce: a permanent failure, usually an invalid or non-existent address. You should stop sending to this address going forward.
- Soft bounce: a temporary failure — a full inbox, a receiving server that's temporarily down, a size limit. Worth retrying, not worth permanently removing the address over.
- Complained — the recipient marked the message as spam. This should also stop future sends to that address, since continuing to send after a complaint actively damages your sender reputation.
Getting hard bounces and complaints out of your active sending list — generally called a suppression list — is one of the more consequential things you can do for deliverability. Continuing to email addresses that have hard-bounced or complained is a direct signal to receiving mail servers that you're not managing your list well, which affects whether other emails you send land in an inbox at all.
Why Polling Isn't a Good Fit for This
You could, in principle, periodically check a delivery log for every email you've sent and update your own records accordingly. In practice, this doesn't scale well: it means running a recurring job, tracking which emails you've already checked, and accepting a delay between when something actually happened and when your system finds out about it. For something like a bounce that should trigger immediate suppression, that delay is exactly the gap where a second email might go out to an address that's already known to be invalid.
Webhooks invert this. Instead of your application asking "did anything happen?" on a schedule, the provider tells you the moment something does.
What This Looks Like in Practice
A webhook endpoint is just a URL on your server that accepts POST requests. When you register it with a provider like Notify and specify which events you care about, the provider sends an HTTP request to that URL every time one of those events occurs. A minimal handler might look like this:
app.post('/webhooks/email', async (req, res) => {
const event = req.body;
if (event.type === 'bounce' && event.bounceType === 'hard') {
await suppressionList.add(event.recipient);
}
if (event.type === 'delivered') {
await markEmailDelivered(event.messageId);
}
res.sendStatus(200);
});
The specific field names vary by provider, but the shape is consistent: an event type, the affected recipient or message, and enough context to act on it. Responding quickly with a success status matters too — most providers expect an acknowledgment and will retry if your endpoint doesn't respond promptly, so it's worth queuing heavier processing (like updating a database) rather than doing it inline before responding.
Webhook Support Across the Category
Notify includes webhooks starting on its Pro plan ($10/month), alongside delivery logs available on every plan (48-hour retention on the free tier, permanent on Pro and Scale). The combination covers both sides of tracking: logs for checking delivery history yourself, and webhooks for reacting to events like delivery and bounces as they happen, without polling. Domain verification and webhook setup are both handled through the same API you're already using to send — there's no separate product or dashboard-only feature to configure.
This same general capability — webhook-based delivery and bounce tracking — is standard across the category rather than unique to any one provider. Postmark, Mailgun, SendGrid, and Resend all support webhooks for delivery and bounce events too. Amazon SES supports the same underlying concept but routes it through Amazon SNS rather than a webhook you configure directly in a dashboard — functionally similar once set up, but with AWS-specific configuration (topics, subscriptions, IAM permissions) in between.
Frequently Asked Questions
What is Notify?
Notify is a lightweight transactional email API for developers. It sends email through a single endpoint, verifies sending domains (SPF/DKIM/DMARC), keeps delivery logs, and offers webhooks on Pro and Scale plans — with no marketing tools, template builder, or bulk-sending features.
What's included in Notify's free plan and paid plans?
Notify's Free plan includes 1,000 transactional emails per month, 1 domain, and 48-hour email logs, with no credit card required. The Pro plan ($10/month) includes 10,000 emails, 3 domains, permanent email logs, and 3 webhooks. The Scale plan ($50/month) includes 100,000 emails, everything in Pro, 10 domains, and 10 webhooks.
What's the difference between a hard bounce and a soft bounce?
A hard bounce is a permanent failure — typically an invalid or non-existent email address — and the address should be suppressed from future sends. A soft bounce is temporary, such as a full inbox or a receiving server that's briefly unavailable, and generally warrants a retry rather than permanent removal. Treating both the same way, either by retrying hard bounces or permanently suppressing soft bounces, causes its own problems.
Do I need webhooks if I already have delivery logs?
Not necessarily. Logs are enough if checking delivery status manually, on your own schedule, is sufficient for your use case. Webhooks matter once you want your application to react automatically and immediately — suppressing a bounced address before the next send goes out, or updating a user-facing status the moment an email is confirmed delivered.
Why does suppressing bounced addresses matter for deliverability?
Continuing to send to addresses that have hard-bounced or been marked as spam is a signal to receiving mail servers that a sender isn't maintaining their list, which can affect whether future emails — even to valid addresses — land in the inbox or get filtered. Automatically suppressing these addresses via webhook events is one of the more effective, low-effort ways to protect sender reputation.
Top comments (0)