SendGrid Event Webhook: Send Email Events to Sazabi

Webhook facts checked on the platform’s docs on Nov 8, 2026.

SendGrid reports what happens to every message it handles through its Event Webhook: queued, delivered, bounced, opened, clicked. If you send transactional email, that stream is the record of whether a password reset or receipt reached anyone.

What the Event Webhook sends

SendGrid posts events to a URL you choose. Each request carries a JSON array, and each element is one event with an event field naming its type.

The reference groups the types. Delivery events are processed, dropped, delivered, deferred and bounce. Engagement events are open, click, spamreport, unsubscribe, group_unsubscribe and group_resubscribe. A separate group covers account status changes. In the Event Webhook settings you tick the types you want in Actions to be posted.

Why send it to Sazabi

A bounce rate is a number in a dashboard. The events behind it are individual rows, each with a recipient, a reason and a message ID. Sazabi's Webhook Events source keeps each one as a searchable log record, so you can look at bounces next to the application logs from the code that sent the mail.

SendGrid's batching fits the source well. Sazabi turns a JSON array into one record per element, so a request with fifty events becomes fifty records. Sazabi accepts only JSON, and SendGrid sends JSON, so no conversion step is needed.

Set it up in SendGrid

1. In SendGrid, go to Settings, then Mail Settings.
2. Under Webhook Settings, select Event Webhooks, then Create new webhook.
3. Set Post URL to your Sazabi intake URL. Add a suffix such as /sendgrid and Sazabi stores it as webhook.path.
4. Under Actions to be posted, select the event types you want.
5. Leave Security features off unless you plan to verify requests elsewhere.
6. Select Test Your Integration, then Save.

Only Post URL and Actions to be posted are required. The test sends example events, not data from a real send, so send one real message afterward to see live traffic.

Example payload

An abbreviated request with one delivered event and one bounce, using property names from the SendGrid docs. It is an example, not a captured request.

[
  {
    "email": "alex@example.com",
    "timestamp": 1513299569,
    "event": "delivered",
    "sg_event_id": "rWVYmVk90MjZJ9iohOBa3w==",
    "sg_message_id": "14c5d75ce93.dfd.64b469.filter0001.16648.5515E0B88.0",
    "response": "250 OK"
  },
  {
    "email": "sam@example.com",
    "timestamp": 1513299570,
    "event": "bounce",
    "type": "bounce",
    "status": "5.1.1",
    "reason": "550 5.1.1 The email account does not exist"
  }
]

After ingestion, search for a field from the payload, such as webhook.event, to filter by type, or search for a recipient address to follow one message.

What to watch for

• Bounce and dropped volume. A jump in bounce or dropped events is worth checking against recent list imports or DNS changes. Compare counts per hour across days.
• Deferred events. deferred means the receiving server rejected the message for now. A growing count means receiving servers are turning mail away for now.
• Gaps. If delivery events stop while your app is still sending, check the webhook before the sender.
• Duplicates. Retries mean the same event can arrive twice. sg_event_id identifies an event.
• Engagement noise. open and click events outnumber delivery events quickly. Select them only if you will search them.

The Intake page in the Sazabi dashboard shows ingestion volume per source, which makes a gap easy to see.

Retries

SendGrid expects a 2xx response. Any other response is retried at increasing intervals for up to 24 hours after the event occurs. Make sure you aren't blocking SendGrid's sending IP addresses, which the docs say change often.

SendGrid can sign requests with an ECDSA key pair. If you also take form submissions, the Typeform page covers the same pattern, and Shopify covers store events.