What are webhook event feeds?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
Imagine getting a tap on the shoulder every time something happens with one of your emails, instead of checking your dashboard every hour. That's what a webhook event feed does.
When your ESP sends a message and something happens (it's delivered, opened, clicked, bounced, or someone unsubscribes), it fires an HTTP POST request to a URL you specify. That request contains structured data about the event: which subscriber, which message, what action, and when. Your server receives it, processes it, and stores it however you like.
The alternative to webhooks is polling: you ask the ESP's API "what happened in the last hour?" on a schedule. Webhooks flip that. The data comes to you in real time, without you having to ask.
Why does this matter practically? If someone marks your message as spam, you want to know immediately so you can suppress them before the next send. If a purchase confirmation bounces hard, your CRM should update in seconds, not hours. Webhooks make that possible.
Most major ESPs support them. Postmark, SendGrid, Mailgun, Klaviyo, and others call them by slightly different names (event streams, event notifications, delivery webhooks) but the concept is the same.
To set one up you'll need a server endpoint that can accept POST requests and respond with a 200 OK. Most ESPs retry if your endpoint is slow or down, but not indefinitely. If reliability matters, add a queue between your webhook receiver and your processing logic.
For more on how complaint data is packaged, see the ARF format for feedback reports. If you're trying to reconcile webhook data with your ESP dashboard, our notes on raw logs vs aggregated reports explain the gap. Stuck on setup? The Review My Emails SOS hotline is free if you need a second pair of eyes.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
