Overview
Webhooks are how modern software systems talk to each other in real time. When an order is placed in your ecommerce platform, a webhook tells your fulfilment system. When a payment succeeds or fails in Stripe, a webhook updates your subscription state. When a trade executes on an exchange, a webhook triggers your risk system. When a deployment completes in your CI pipeline, a webhook notifies your team. The pattern is everywhere because it works — push-based event delivery is more efficient, more timely, and more reliable than polling-based integration when it is implemented correctly.
When it is implemented incorrectly, webhooks become a source of operational problems that are difficult to diagnose. Events arrive out of order and the receiving system processes them in sequence. Duplicate events arrive and produce duplicate records. The receiving endpoint is temporarily unavailable and events are lost. The payload format changes without notice and the integration silently stops processing. The volume of events spikes and the receiving system falls behind.
We build webhook integrations that handle these conditions correctly — both the webhook receivers that accept and process events from external systems, and the webhook senders that deliver events from your systems to external consumers reliably. The difference between a webhook integration that causes operational problems and one that does not is almost entirely in how these edge cases are handled.
Receiving Webhooks
Endpoint design and security. A webhook receiver is an HTTP endpoint exposed to the internet that accepts POST requests from an external system. The security model is critical — any exposed endpoint will be discovered and probed, and a webhook receiver that processes any POST request without validation is a security liability. We implement signature verification for every webhook receiver — validating the HMAC signature or equivalent authentication mechanism provided by the sending platform against the payload before processing begins. Requests that fail signature verification are rejected immediately with a 401 response, before any processing occurs.
Endpoint design covers the full receiving surface: the URL structure that identifies the event source, the HTTP method and content type handling, the response behaviour that tells the sender whether delivery was successful, and the timeout handling that prevents the endpoint from leaving sender connections open when processing takes longer than expected. Webhook senders typically retry delivery when they do not receive a success response within their timeout window — the receiver needs to respond quickly and process asynchronously rather than making the sender wait for processing to complete.
Idempotency. Webhook senders retry delivery when they do not receive confirmation. A retry that arrives after the original delivery was processed would, without idempotency handling, produce duplicate records, duplicate charges, duplicate fulfilment actions, or duplicate notifications. We implement idempotency at the receiver — tracking processed event identifiers and detecting duplicates before processing begins. The idempotency window covers the retry window of the sending platform — events that arrive within that window are deduplicated, events outside it are processed normally.
Ordered processing. Many webhook systems deliver events with no guarantee of ordering — two events for the same object may arrive in reverse chronological order. Processing them in arrival order without checking their sequence produces incorrect final state. We implement sequence-aware processing for event types where ordering matters — using event timestamps or sequence numbers to detect and handle out-of-order delivery, queuing events that arrive ahead of their predecessors, and applying events in the correct sequence regardless of arrival order.
Async processing and queuing. Webhook receivers that perform synchronous processing — querying databases, calling external APIs, running business logic — within the HTTP request handler will time out for slow operations and cause the sender to retry, creating duplicate delivery problems. We separate receipt from processing: the receiver endpoint validates the request, acknowledges it immediately with a 200 response, enqueues the payload for processing, and returns. Processing happens asynchronously from the queue, independently of the delivery connection.
Failure handling and dead letters. Processing failures — validation errors, downstream system unavailability, unexpected payload structures — need to be handled without losing the event. We implement retry logic for transient failures, dead letter queues for events that exhaust retries, and alerting that surfaces processing failures before they accumulate into operational problems.
Schema validation. Webhook payloads change. Platforms update their payload structures, add fields, remove fields, or change field types across API versions. A receiver that trusts the payload structure without validating it will fail silently or incorrectly when the payload changes. We implement schema validation at the receiver boundary — validating that the payload contains the fields the processing logic depends on before processing begins, and routing invalid payloads to a dead letter queue with logging that captures the full payload for diagnosis.
Sending Webhooks
Building a system that delivers webhooks to external consumers — a platform delivering events to customer-configured endpoints, an application notifying downstream systems of state changes — requires delivery infrastructure that is reliable, observable, and operationally manageable.
Delivery reliability. HTTP delivery is inherently unreliable — the destination endpoint may be temporarily unavailable, may time out, or may return an error. Reliable delivery requires retry logic that re-attempts failed deliveries with appropriate backoff, persistence that ensures events are not lost if the delivery service restarts, and dead letter handling for events that exhaust retries.
We build webhook delivery infrastructure with explicit delivery guarantees — at-least-once delivery with idempotency key support for consumers that need to deduplicate, configurable retry schedules with exponential backoff and jitter, and maximum retry limits with dead letter routing for events that cannot be delivered after exhausting retries.
Delivery ordering. For consumers that depend on processing events in the order they were generated, delivery infrastructure needs to maintain per-resource ordering — events for the same object delivered in sequence, even when the delivery infrastructure is handling many events concurrently. We implement per-resource delivery queues that maintain ordering within a resource while allowing concurrent delivery across different resources.
Signature generation. Consumers need to verify that webhook deliveries originate from the expected sender and have not been tampered with in transit. We implement HMAC-SHA256 signature generation on outbound webhook payloads — generating a signature from the payload and a per-consumer secret, including it in the delivery headers, and providing consumers with the verification code or documentation they need to validate it.
Consumer management. Platforms delivering webhooks to customer-configured endpoints need administrative infrastructure: endpoint registration and management, event type subscription configuration, per-consumer secret management, delivery log visibility that lets consumers inspect recent deliveries and their outcomes, and manual retry capability for failed deliveries. We build consumer management interfaces as part of webhook delivery platforms.
Payload design. Webhook payloads that contain the full context of the event — the complete state of the object at the time the event occurred — are easier for consumers to process than thin payloads that require the consumer to make a follow-up API call to fetch the current state. We design webhook payloads to be self-contained — including the entity identifier, the event type, the timestamp, and the full relevant state — while keeping payload size manageable.
Platform-Specific Webhook Integrations
We have built webhook integrations across the full range of platforms in our integration portfolio:
Payment platforms. Stripe and Mollie webhook receivers handle the full event surface — payment intent lifecycle events, subscription status changes, invoice events, dispute notifications, and payout events — with the signature verification, idempotency handling, and ordered processing that payment event handling requires. Payment events have direct financial consequences if processed incorrectly — a failed payment event processed as successful, or a successful payment event processed twice, produces real money errors.
Ecommerce platforms. Shopify, WooCommerce, and Bol.com webhook receivers handle order lifecycle events, inventory updates, product changes, and customer events. Ecommerce webhook volumes can be high during peak periods — flash sales, promotional events — and the receiver infrastructure needs to handle burst traffic without falling behind.
Logistics platforms. SendCloud, MyParcel, and PostNL webhook receivers handle shipment status updates — label creation, pickup confirmation, in-transit scans, delivery confirmation, exception notifications — with the event ordering logic that shipment status processing requires.
Communication platforms. Slack, Microsoft Teams, and Twilio webhook receivers handle interaction events — slash command responses, message actions, SMS delivery receipts, voice call events — with the synchronous response requirements that interactive platform events impose.
Trading platforms. TradingView alert webhooks deliver trading signals to execution infrastructure. Exchange webhooks deliver order and position update events. The latency requirements of trading webhook processing are more demanding than most other webhook use cases — signals that arrive late are signals that miss their entry window.
Development platforms. GitHub, GitLab, and CI/CD platform webhooks trigger deployment pipelines, synchronise issue tracking, and notify teams of build and deployment events. Development platform webhooks are the connective tissue of automated development workflows.
CRM and business platforms. Salesforce, HubSpot, Exact Online, and AFAS webhook receivers handle CRM events, ERP state changes, and business process events — synchronising state across the business platforms that operational workflows depend on.
Observability and Operations
Webhook integrations that cannot be observed are integrations that cannot be maintained. When an integration silently stops processing events, the operational problem it causes — orders not fulfilled, payments not recorded, notifications not sent — may not surface until significant damage has been done.
Delivery logging. Every webhook event received or sent is logged — the full payload, the processing outcome, the processing duration, and any errors encountered. Delivery logs are the primary diagnostic tool when an integration behaves unexpectedly.
Processing metrics. Event volume, processing latency, success rate, failure rate, and queue depth are instrumented and monitored continuously. Anomalies — a spike in failure rate, a growing queue depth, a drop in event volume that indicates the sender has stopped delivering — are surfaced through alerting before they become operational problems.
Replay capability. When a processing failure has caused events to be missed or incorrectly processed, replay capability allows those events to be reprocessed from the delivery log without requiring the sending platform to re-deliver them. Replay is essential for recovery from processing bugs, dependency outages, and the inevitable edge cases that production webhook processing encounters.
Alerting. Webhook processing failures, delivery failures, dead letter queue growth, and anomalous event patterns trigger alerts through configured channels — Slack, email, or PagerDuty-compatible endpoints — so that operational problems are caught and addressed before they escalate.
Technologies Used
- Rust / Axum — high-performance webhook receiver endpoints, latency-sensitive processing, high-volume event ingestion
- C# / ASP.NET Core — webhook integration services with complex business logic and enterprise system connectivity
- Next.js / TypeScript — webhook receivers integrated into full-stack web applications
- SQL (PostgreSQL, MySQL) — event persistence, idempotency tracking, delivery logging
- Redis — event queuing, processing state, idempotency key storage, rate limiting
- REST / HTTP — webhook delivery and receipt over standard HTTP
- HMAC-SHA256 — webhook signature verification and generation
- Stripe / Mollie — payment platform webhook integration
- Magento / Shopify / WooCommerce / Bol.com — ecommerce webhook integration
- SendCloud / MyParcel / PostNL — logistics webhook integration
- Slack / Teams / Twilio — communication platform webhook integration
- TradingView — trading signal webhook integration
- Salesforce / HubSpot / Exact Online / AFAS — CRM and ERP webhook integration
- GitHub / GitLab — development platform webhook integration
When Webhook Integrations Go Wrong
The operational problems caused by poorly implemented webhook integrations follow predictable patterns. Duplicate records in the database because idempotency was not implemented. Incorrect state because events were processed out of order. Lost events because the receiver was unavailable during a retry window and no persistence was in place. Silent integration failures because no monitoring was built. Payload parsing failures that go undetected because schema validation was not implemented.
These problems are not hard to prevent — they are hard to fix after the fact, because the data the integration produced is already in production systems and needs to be cleaned up alongside fixing the integration. The cost of implementing idempotency, ordering, persistence, and monitoring correctly from the start is a fraction of the cost of diagnosing and recovering from the problems that missing these produce.
Connect Your Systems Reliably
Webhook integrations are the real-time nervous system of modern software architectures. When they work correctly they are invisible infrastructure. When they do not, the consequences show up in every system they connect.