SendGrid sends an avalanche after every campaign. We hold it back for your server.
SendGrid event webhooks bundle delivered, opens, clicks, bounces and spam reports in rapid bursts. At the wrong moment that knocks your server over — exactly when you need the data most. WebhookFlow accepts them instantly, validates the signature and forwards at your pace.
Why SendGrid webhooks pose specific challenges
Burst pattern after every campaign
Send a newsletter to 50,000 recipients and SendGrid pushes 49,000+ delivered events within minutes. Opens and clicks roll in over the following hours. A server that normally runs smoothly can choke on this volume.
Signature validation is required but error-prone
SendGrid signs webhooks with ECDSA. Misconfigured and your server accepts forged events; too strict and you reject legitimate ones. WebhookFlow validates centrally per the SendGrid spec, so you don't have to implement it yourself.
No persistent retries on downtime
SendGrid retries failed webhook calls but eventually gives up. If your server is offline during a release window or short outage you permanently lose part of your event data. No automatic recovery later.
Many event types on one endpoint
SendGrid sends at least eleven different event types to the same endpoint. Filtering, routing and dispatching correctly in your application takes code and test time. WebhookFlow can route by event type to different endpoints — no if-else trees in your code.
What WebhookFlow specifically does for SendGrid
Burst buffer with rate limiting
Set a safe maximum — for example 100 events per second to your server. If SendGrid sends a thousand at once they queue in the buffer and stream out smoothly. Your application stays available for other users.
Automatic signature validation
Configure your SendGrid public verification key once; WebhookFlow then checks every incoming request. Forged events are rejected before they reach your application.
Persistent retries during your downtime
Server briefly unreachable? WebhookFlow holds events and retries hours or days later if needed — not just the 4 attempts SendGrid stops at.
Routing by event type
Send "bounce" and "spamreport" to your deliverability monitoring, "delivered" to your analytics, "click" to your CRM. Configurable without changes on the application side.
Frequently asked questions about SendGrid webhooks
How many events does SendGrid send for a campaign?
For a 50,000-recipient list expect 49,000-50,000 delivered events within minutes, plus opens (typically 20-30%), clicks (1-5%), and bounces in the following hours. Easily 100,000+ events per campaign, with peaks of hundreds per second.
What does it cost to just handle SendGrid webhooks on my own server?
Generally nothing — until it goes wrong. A crash during a large campaign permanently loses you event data (delivered? opened? bounced?). For anyone who takes marketing reporting seriously that's reason enough for a buffer. Plus: implementing signature validation correctly takes engineering time.
Does this work with SendGrid Marketing Campaigns and Transactional?
Yes. SendGrid uses the same event webhook mechanism with the same event types for both products. WebhookFlow supports all SendGrid event categories — transactional gives you a steadier stream, marketing produces sharper bursts.
How do I configure this on the SendGrid side?
In SendGrid set the event webhook URL to the WebhookFlow endpoint we create for you. Copy your public verification key into WebhookFlow for signature validation. A complete setup takes under five minutes.
No more crashes after every campaign
WebhookFlow is in development and looking for beta users. Sign up for early access.