What Is Webhook?

Webhook Explained

Webhooks invert the normal API relationship. With a conventional API the consumer asks repeatedly whether anything has changed; with a webhook the producer tells the consumer the moment something does. The consumer registers a publicly reachable endpoint and subscribes to event types. When an order ships, an invoice posts, or a work order closes, the producer sends an HTTP POST containing an event identifier, type, timestamp, and a payload describing what happened.

The efficiency argument is straightforward. Polling an ERP every minute for changed orders generates 1,440 requests a day per object, nearly all of which return nothing, while still introducing up to a minute of latency. A webhook produces exactly as many requests as there are events and delivers them in seconds. The cost is architectural: the consumer must operate a reachable, authenticated, highly available endpoint, because a producer with nowhere to deliver an event will retry for a while and then give up.

Security must be designed in, because a webhook endpoint is by definition exposed. The standard control is a signature: the producer computes an HMAC over the raw request body using a shared secret and sends it in a header, and the consumer recomputes and compares it in constant time before trusting anything. A timestamp in the signed payload with a short acceptance window prevents replay of captured requests. Endpoints should never trust payload contents purely because they arrived at the expected URL.

Delivery semantics are at-least-once, not exactly-once, and ordering is not guaranteed. Networks fail after the receiver has already committed, so producers retry with exponential backoff and consumers see duplicates. Consumers must therefore be idempotent, typically by recording the event identifier and ignoring repeats, and must tolerate an update event arriving before its create event. The practical pattern is to acknowledge fast with a 2xx after durably queueing the event, then process asynchronously, so slow downstream work never causes the producer to consider delivery failed.

In ERP landscapes webhooks are how event-driven integration usually starts. Salesforce and ServiceMax publish platform events and outbound messages, integration platforms expose webhook triggers, and on-premises ERPs are commonly extended with database triggers or business rules that call an outbound endpoint. Where the ERP is behind a firewall, the pattern reverses again: an agent inside the network polls or subscribes and forwards outward, since inbound connections to the ERP host are usually prohibited.