Webhook Endpoint
Pronunciation: WEB-hook END-poynt
Definition
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. Common risks include slow processing and body modification before signature checks.
Overview
How it works and where it fits
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.
Related glossary concepts
Webhook Subscription; Webhook URL; Webhook Log
Primary reference
Example
A store exposes https://example.com/hooks/payment for notifications. Its server receives a signed payment event, validates the signature using the raw request body, records the event ID and queues an order-state check. It replies promptly to the sender; expensive fulfillment processing happens asynchronously after authorization and deduplication.
Comparison
The endpoint is the receiver URL and code, not the publisher's delivery guarantee. Accept only expected methods and schemas, protect secrets, limit payload size and verify authenticity before changing business state. An HTTP 200 means the delivery was acknowledged, not that the payment was independently verified on-chain or the order shipped.
Key Takeaway
Verify origin and persist an event before triggering irreversible downstream business actions.
Sources
- Webhook — OxaPay (2026-08-03)
- Best Practices for Using Webhooks — GitHub (2026-08-03)
- HTTP Semantics — IETF (2026-08-03)