How it works
Three things that need to be in place for a webhook to work.
Component 1
An event in the sending system
Something has to happen for a webhook to fire. A new contact created. A deal moved to a new stage. An order completed. The sending system needs to be configured to fire the webhook when this specific event occurs. Most modern SaaS tools have webhook settings that let you choose which events trigger a notification and where to send it.
Component 2
A URL in the receiving system
The receiving system needs to expose a URL that it is listening on, a webhook endpoint. When the event fires in system A, system A sends an HTTP POST request to this URL, containing the event data as JSON. The receiving system processes the data and sends back a 200 response to confirm it received it.
If the receiving system does not respond with 200, the sending system usually retries. The retry logic varies by platform, some try three times, some try indefinitely with backoff. This is why a webhook endpoint that fails silently (returns 200 without actually processing the data) can cause problems: the sender thinks it worked, but it did not.
Component 3
Logic in the receiving system
Receiving the webhook is not the same as doing something useful with it. The receiving system needs logic that processes the incoming data and takes the appropriate action: creating a record, updating a status, triggering a workflow, sending a notification.
This logic is where most webhook implementations get complicated. The data that arrives may not match exactly what the receiving system expects. Fields may be named differently. Required fields may sometimes be missing. The receiving system needs to handle these cases explicitly rather than failing silently when the incoming data does not match the expected format.
The key difference from APIs
APIs pull. Webhooks push.
An API call is a request-response: you ask for data and get a response. You initiate it. A webhook is a notification: the other system tells you something happened. They initiate it.
Use an API when you need data on demand, you want to look up a specific record, run a query, or fetch the current state of something. Use a webhook when you need to react to events, something changed in another system and you want to know immediately rather than checking periodically.
