Webhook Consumer

Overview

A Webhook Consumer is the application component that receives, validates, stores, and processes webhook events. It is broader than the webhook handler when processing continues after the initial HTTP request through queues, workflows, or domain services. The Webhook Consumer path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state.

The main risks include duplicate side effects, accepting forged events, out-of-order updates, queue backlog, schema drift, and unbounded processing failures. It may be an HTTP endpoint plus asynchronous workers that convert external notifications into internal state changes.

In production, teams should define ownership and apply signature verification, schema validation, durable inbox, idempotent processing, ordering policy, retry handling, and observability. For Webhook Consumer, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.

Useful measures include consumer success rate, processing latency, duplicate suppression rate, queue age, and dead-letter volume. Webhook Consumer is closely connected to Webhook Handler, Idempotent Consumer, and Webhook Deduplication. Replay of Webhook Consumer should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event.

A receiver should treat transport acknowledgement and successful downstream processing as separate states for Webhook Consumer. Recovery for Webhook Consumer should combine replay controls with an authoritative status check rather than trusting delivery history alone.

A Webhook Consumer handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response. Business actions triggered by Webhook Consumer should be idempotent and should verify the current object state before fulfillment or accounting updates.