SendGrid's Event Webhook posts a JSON payload to a URL you specify every time something happens to a message you sent: it's delivered, opened, clicked, bounced, marked as spam, or dropped before it ever left. A separate feature, Inbound Parse, runs the other direction, posting incoming email your domain receives to a webhook instead of a mailbox. Both are just HTTP POSTs until you build something that reads them. We build the listener, the routing logic, and the destination, so a bounce or a complaint actually changes something somewhere else in your business instead of sitting in a log.
Turn it on under Settings > Mail Settings > Event Webhook (or the equivalent API endpoint) and pick which event types you want posted: processed, delivered, open, click, bounce, dropped, deferred, spam report, unsubscribe, and group unsubscribe/resubscribe for sends using subscription tracking. Each event arrives as a JSON object carrying the recipient address, your own custom message metadata if you set any, a timestamp, and event-specific fields, a bounce reason and type for bounces, the clicked URL for a click.
SendGrid batches events and can send more than one per request, so the endpoint you build needs to parse an array, not assume one event per POST. SendGrid also signs the payload if you enable signed event verification, which your endpoint should check before trusting the contents, since the URL is otherwise a public endpoint anyone could post to.
Inbound Parse is a separate setup: you point an MX record at SendGrid, and incoming mail to that domain gets parsed and posted to your webhook as structured fields (from, to, subject, body, attachments) instead of landing in an inbox. It's the feature behind things like a support address that turns a reply into a ticket automatically, or a reply-to address that updates a record instead of going nowhere.
A webhook endpoint that just logs the payload tells you SendGrid is working. It doesn't suppress a bad address, alert anyone about a spike in bounces, or turn a parsed inbound email into a ticket. That's the part that has to be built deliberately: a route for each event type that decides what should happen next, and a destination, a CRM field, a Slack message, a ticketing system, that actually does something with it.
The signature verification step also trips up a lot of first attempts at this. Skipping it means the endpoint will happily process a forged request claiming a bounce that never happened, which matters more than it sounds like once something downstream (suppressing an address, closing an account flag) acts automatically on what the webhook says.
Every event type lands somewhere specific: a bounce updates the contact record, a spam complaint flags the account, a click feeds engagement data back to wherever your team actually looks at it, with signature verification checked before any of it runs.
A reply to a parsed inbound address turns into a new support ticket or an update to an existing record automatically, instead of arriving as an email nobody's watching.
Tell us which event types matter most to your business, bounces, spam complaints, inbound replies, and we'll scope what it would take to route them automatically.
Tell us what you'd want to know the moment a bounce, complaint, or inbound reply comes through, and where it should land once it does. We'll build the listener that connects the two. And if the real bottleneck in your business isn't email events at all, we automate whatever manual step is actually costing you time.
Let's talk →Processed, delivered, open, click, bounce, dropped, deferred, spam report, unsubscribe, and group unsubscribe/resubscribe (for sends using subscription tracking), depending on which event types you enable under Mail Settings.
Yes. SendGrid batches events into arrays rather than guaranteeing one event per POST, so an endpoint built to only read the first item in the payload will silently drop the rest.
A separate feature from the Event Webhook: you point an MX record at SendGrid, and incoming email to that domain gets parsed into structured fields and posted to a webhook URL instead of landing in a mailbox.
Yes, if the webhook triggers anything that matters, suppressing an address, flagging an account. Without signature verification, the endpoint is a public URL that will process a forged request as readily as a real one.
SendGrid retries failed webhook deliveries for a period before giving up, but the exact retry window and backoff behavior are documented on SendGrid's side and worth checking directly rather than assuming, since it changes how much downtime your endpoint can tolerate before an event is lost for good.