What Webhooks Are (and Aren't)

A webhook is an HTTP POST request sent from one system to another when something happens. Instead of your server asking "did anything change?" repeatedly (polling), the other system tells you proactively.

When a payment completes, Stripe sends a POST to your /webhooks/stripe endpoint with the payment details. When a file is uploaded to S3, you can configure S3 to notify a Lambda function. When a customer interacts with your email, SendGrid POSTs the event to your system.

Webhooks are simple by design: they're just HTTP requests. But the simplicity hides several failure modes that matter in production.

Building a Webhook Receiver That Doesn't Lose Events

Verify signatures. Every major webhook provider signs their payloads with a shared secret. Always verify this signature before processing. Skipping verification means any HTTP client can send fake events to your endpoint.

Return 200 quickly, process asynchronously. Your webhook endpoint should acknowledge receipt within a second or two. If you process the event synchronously (send an email, update a database, call another API), and any step takes longer than your provider's timeout, they'll retry — potentially multiple times. Instead: write the raw payload to a queue, return 200, process from the queue asynchronously.

Handle duplicates. Webhook providers retry on network errors, timeouts, and non-2xx responses. This means your endpoint will receive the same event more than once. Design your handlers to be idempotent — processing the same event twice should produce the same result as processing it once. Store processed event IDs and check for duplicates before acting.

Log everything. Store the raw payload of every webhook received, with a timestamp and processing status. When a customer says "my payment processed but my account wasn't activated," your first step is checking the webhook log for that payment event.

Publishing Webhooks: Let Your Customers React to Your Events

The other direction matters too. If you're building a developer-facing or integration-heavy SaaS product, your customers will want to receive webhooks from you — so their systems can react when things happen in yours.

A basic outbound webhook system needs:

• A way for customers to register webhook endpoints (URL + event types they want to receive)
• Reliable delivery with retries on failure (with exponential backoff)
• A dashboard where customers can see delivery history and re-trigger failed deliveries
• Signature verification so customers can confirm events came from you

Svix and Hookdeck are managed services that handle the infrastructure complexity of outbound webhooks — event storage, retries, delivery logs, and customer portals — so you don't build and maintain it yourself. For most startups, this is the right call.

When to Use Event-Driven Architecture More Broadly

Webhooks are a specific form of a broader pattern: event-driven architecture. Instead of services calling each other directly, services publish events to a message bus, and other services subscribe to the events they care about.

At the startup stage, you rarely need a full event-driven architecture (Kafka, RabbitMQ, event sourcing). But there are specific patterns worth adopting early:

Job queues for background work. Anything that takes more than a second to complete — sending emails, generating reports, processing uploads, calling external APIs — belongs in a background job queue, not in a synchronous request handler. BullMQ (Node.js + Redis) and Celery (Python) are standard choices.

Database change events. Some workflows need to react to any change in a table, regardless of where that change originated. PostgreSQL's LISTEN/NOTIFY or logical replication gives you a change stream you can consume without modifying application code.

Scheduled events. Cron jobs that check for things to process are a polling-based event system. They work, but they introduce latency proportional to the cron interval. If something needs to happen within seconds of a state change, an explicit event is more reliable than a polling job.

Event-driven patterns solve real problems as your product grows. The investment in learning them early pays dividends every time you add an integration, automate a workflow, or scale a workload that can't live on the synchronous request path.