The honest answer, before the mechanism
You can wire up an endpoint, verify the HMAC signature, and branch on event type yourself, and the rest of this page walks through exactly how. Or you can let your agent watch the stream: Claude, Cursor, or Codex reading delivered, bounced, and complained, and deciding what happens next without you writing the handler. I think that second path is where email automation is actually heading, and it's why Nitrosend ships an MCP server alongside the webhook rather than just a payload schema and a signing secret.
What a webhook is
A webhook is an HTTP callback. Instead of your app repeatedly asking an API whether anything changed, the platform pushes the event to your URL when it happens. You register an endpoint, the sender POSTs a payload to it, your app reacts.
That is the entire mechanism. A payload, a target URL, and a POST. Everything else written about webhooks is detail on those three parts.
Webhook vs API
An API is you asking. A webhook is being told. You call an API when you want something done or fetched right now. You register a webhook when you want to know the moment something happens without asking every minute.
Most production stacks need both, and email is the clean example: the API sends the message, the webhook tells you what happened to it.
What email events look like
A transactional send emits events as it moves: sent, delivered, opened, clicked, bounced, complained, failed, and received when a reply reaches your inbox. A webhook hands the ones you subscribe to to your app as they happen.
{
"type": "email.bounced",
"timestamp": "2026-07-17T02:14:09.000Z",
"data": {
"message_id": 48213,
"to": "[email protected]",
"bounce": { "type": "soft", "subtype": "MailboxFull" }
}
}
Here is the part I care about. Events used to land in a dashboard where a human noticed them on Tuesday. Now they belong in your agent's hands. A bounce fires, the agent suppresses the contact, and you read about it afterwards. Inside Nitrosend, the single most-used agent tool is the one that reads sending data: agents are analytics-first. They act on events. A dashboard just displays them.
Event semantics matter more than people think. In one of our own incidents, individual sends bounced while every flow stayed live and nothing needed a retry: the events told the whole story, precisely scoped. A system that only said "something failed" would have had us pausing healthy automations.
Bounce events are also how you find out the list someone imported was a graveyard. A single Brevo campaign of ours once generated 8,730 suppressions on its own: 3,708 hard bounces, 3,904 soft bounces, 1,105 unsubscribes, and 13 spam complaints. George Hartley's advice when someone wants to blast an old list one more time is blunt: take that list out back and burn it. At SmartrMail we wired bounce events all the way into billing, so undeliverable contacts dropped off your bill automatically. That is what events are for. They should change what the system does next, not decorate a chart.
Testing and securing a webhook
Point it at a request bin. Or a local tunnel. Fire a test event and inspect the payload before writing a line of handler code.
Verify the signature. Anyone can POST to a public URL. Nitrosend signs every event with HMAC-SHA256, so your handler checks the signature before trusting the payload.
Respond fast, process later. Return 200 immediately and queue the work. Failed deliveries are retried with exponential backoff, so a slow handler means duplicate processing.
Handle bounced and complained on day one. Suppress those addresses automatically. That single handler protects your sender reputation more than anything else on this page. Delivery events are also how you keep bounce rate honest, and they matter most on transactional email, where a single failed receipt is a support ticket.
Go deeper
FAQ
What is a webhook?
A webhook is an HTTP callback: instead of your app polling an API for changes, the platform POSTs the event to your URL the moment it happens. For email, that means delivered, opened, and bounced arrive as events.
What is the difference between a webhook and an API?
An API is you asking. A webhook is being told. You call an API when you want something done right now; you register a webhook when you want to know the moment something happens. Most production stacks need both.
How do I test a webhook?
Point it at a request bin or local tunnel, fire a test event, and inspect the payload before writing handler code. Then verify the signature: Nitrosend signs every event with HMAC-SHA256, and failed deliveries are retried with exponential backoff.