Webhook Endpoint

Overview

Webhook Endpoint is the server route that receives asynchronous webhook requests from another system. It is used to accept event notifications and hand them into durable application processing. It differs from a webhook URL, which is the full configured address and may include scheme, host, and path.

A typical implementation works as follows: The endpoint terminates HTTPS, reads the raw request, verifies authenticity, validates schema, records the event, returns an acknowledgment, and processes work asynchronously. Business actions triggered by Webhook Endpoint should be idempotent and should verify the current object state before fulfillment or accounting updates.

Common risks include slow processing and body modification before signature checks. Important failure modes include slow processing, body modification before signature checks, duplicate events, unsupported versions, and public exposure. These failures can cause failed or forged updates.

Core controls require teams to verify signatures on raw bytes, use idempotency, queue work, limit payload size, return promptly, and monitor acknowledgments. A receiver should treat transport acknowledgement and successful downstream processing as separate states for Webhook Endpoint.

Operational evidence should include endpoint, event ID, signature status, schema version, response code, latency, retry count, and processing state. Webhook Endpoint should be documented alongside Webhook URL, Callback Verification, and Webhook Failure.

Replay of Webhook Endpoint should preserve original identifiers and timestamps so historical processing cannot masquerade as a new event. For Webhook Endpoint, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing. The Webhook Endpoint path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state.