n-SendGrid's Webhook Fires on Every Event. Something Still Has to Catch It.
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.
What the Event Webhook actually sends
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.
Where receiving the event isn't the same as acting on it
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.
What we build around the SendGrid webhooks
A verified listener that routes by event type
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.
Inbound replies that become tickets or updates
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.
What happens right now when a SendGrid event fires and nobody's looking at the log?
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.
Running SendGrid and still checking the event log by hand?
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