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
Every send emits a stream: sent, delivered, opened, clicked, bounced, complained, unsubscribed, failed. A webhook hands each one to your app as it fires.
{
"event": "bounced",
"message_id": "msg_9f2c",
"recipient": "[email protected]",
"reason": "mailbox_full",
"occurred_at": "2026-07-17T02:14:09Z"
}
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 campaign on our platform once generated 8,730 suppressions on its own: 3,708 hard bounces, 3,904 soft bounces, 1,105 unsubscribes, and 13 spam complaints. My advice when someone wants to blast an old list one more time hasn't changed in a decade: 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.