12 things to verify before going live with webhooks — a battle-tested checklist for production-ready endpoints.
Last updated March 2026. Applicable to Stripe, GitHub, Shopify, and any webhook provider.
Before going live with webhooks, verify these 12 items. Each one has caused production outages at real companies. Walk through them in order, and you'll ship a webhook endpoint that handles the chaos of the real world.
Most webhook providers (Stripe, GitHub, Shopify) expect a 2xx response within 5-30 seconds. If your endpoint is too slow, the provider marks the delivery as failed and retries — creating duplicate events and alert noise. Return 200 OK immediately, then process the payload asynchronously in a background job or queue.
curl or the webhook tester and measure response time from the client. Anything over 3 seconds is a warning sign.Without signature verification, anyone who discovers your endpoint URL can send fake payloads. Every major provider signs webhooks with HMAC-SHA256 or similar. Verify the signature using the provider's SDK or by computing the HMAC yourself against the raw request body.
400 or 401, not 200. Also send a request with no signature header at all. Both must be rejected.Webhook providers retry on failure, network issues, and even occasionally send genuine duplicates. If your handler charges a customer or sends an email on each delivery, duplicates mean double charges or spam. Store the event ID and skip processing if you've seen it before.
Webhook providers add new fields over time and may omit optional fields. If your parser throws on unexpected fields or crashes on missing ones, a routine provider update will break your integration. Use lenient parsing — ignore unknown fields and provide defaults for optional ones.
A provider bug or a burst of activity can send hundreds of webhooks per second. Without rate limiting, this can overwhelm your database, max out worker threads, or trigger cascading failures. Apply per-source rate limiting at the load balancer or application level.
429 Too Many Requests for excess requests rather than crashing or timing out.Webhook payloads often contain sensitive data — customer emails, payment amounts, API tokens. Serving your endpoint over plain HTTP exposes this data to anyone on the network path. Enforce HTTPS and redirect or reject HTTP requests. Most providers won't even send to HTTP URLs.
http:// (not https://). It should either redirect to HTTPS or return an error. Then inspect the certificate chain, hostname, and expiry with your TLS tooling.Your endpoint will occasionally fail — database connection lost, downstream service timeout, deployment in progress. The provider will retry, but you should also handle retries gracefully on your side. Return 503 for temporary failures (not 500) so the provider knows to retry. If you process webhooks asynchronously, build retry logic into your worker.
503 and the event is retried or queued for later processing. See our retry strategies guide.After all retries are exhausted, the event must go somewhere — not just vanish. A dead letter queue (DLQ) captures events that failed all retry attempts so you can investigate and replay them manually. Without a DLQ, you have silent data loss.
500 every time). Send a webhook and exhaust all retries. Verify the event appears in your dead letter queue or error log for manual review.When something goes wrong at 2 AM, your logs are your only friend. Log every webhook delivery with the event ID (or request ID), timestamp, provider name, event type, response status, and processing duration. This lets you correlate with the provider's dashboard and trace issues end-to-end.
A stack trace or database error in your webhook response tells attackers about your tech stack, file paths, and database schema. Return generic error messages ("Internal error") in responses. Log the full details server-side only.
If your handler calls an external API or database that hangs, a missing timeout means the request hangs forever — consuming a connection, a worker thread, or a Lambda invocation. Set explicit timeouts on every I/O call in your webhook handler: database queries, HTTP calls, queue publishes.
A broken webhook handler can silently lose events for hours before anyone notices. Set up alerts that fire when your webhook failure rate exceeds a threshold (e.g., more than 5% of deliveries fail in a 10-minute window). Monitor both your own endpoint metrics and the provider's webhook dashboard.
Use the manual guide to review response handling, signature verification, TLS, error leakage, and related controls.
Review Security Checklist Test Webhooks FreeRelated guides: What is a Webhook? · Webhook vs API · Webhook Security · Retry Strategies · Idempotency
More: What is a Webhook? | Webhook Security Guide | Webhook Idempotency | Retry Strategies | Compare Tools