How to set up CRM webhooks
Pick the trigger event, point it at an endpoint that can receive it, then verify with a real test event. A saved configuration screen that has never fired for real tells you nothing.
The short answer
- A webhook pushes data the moment a trigger event happens: a new deal, a stage change, a new contact. That is different from an API, which the receiving system typically has to pull from on its own schedule.
- The receiving side needs a working endpoint, a server, a serverless function, or a middle-layer tool like Zapier or Make. It has to accept an incoming HTTP request and do something useful with the payload.
- Retry behaviour on failed delivery varies by CRM. Some retry automatically for a period. Others fire once and move on whether or not it succeeded. That matters if the receiving endpoint is ever briefly down.
- A webhook configuration that has never been tested with a real event is not verified. A saved settings screen looks identical whether the webhook works or has been silently broken since setup.
Why a webhook is the right tool for real-time triggers
Webhooks exist for the case where a receiving system needs to know about an event the moment it happens, not on the next scheduled check. A new deal being created. A stage change. An incoming form submission. These are events where a delay of even a few minutes can matter. Polling an API on a schedule, checking every five or ten minutes for anything new, introduces exactly that delay. A webhook pushes the event out at once, as an HTTP request to a URL the receiving system registered in advance.
Setting one up requires two things on the CRM side. Choosing which event should trigger it (not every CRM supports firing on every event type). And specifying the endpoint URL the payload should be sent to. On the receiving side, something needs to be listening at that URL, ready to accept the request and act on the data it contains. That can be custom code, a serverless function, or a no-code tool built to receive webhooks and translate them into another system's action.
Webhook setup checklist
| Step | What to confirm |
|---|---|
| Choose the trigger event | Which specific event types the CRM actually supports firing on |
| Set the receiving endpoint URL | The URL is live, reachable, and expecting this payload format |
| Send a real test event | Not only a saved configuration screen; confirm the payload actually arrives and parses correctly |
| Check retry behaviour | Whether the CRM retries on a failed delivery, and how many times |
| Verify the payload shape | The receiving system correctly reads the fields it needs from the actual payload |
What to actually verify once it is configured
Trigger a real event. Create an actual test deal or contact, rather than relying on a "test" button that may send a synthetic payload different from what a real event produces. Confirm the receiving endpoint got the request, parsed the fields correctly, and did what it was supposed to do with them. Test the failure case too if possible. Briefly point the webhook at an unreachable URL and confirm whether the CRM retries or silently drops the failed delivery. Then you know what to expect if the endpoint is ever down in production.
Disclosure: SalesCrew is our product. Its outbound webhooks support common CRM events with delivery logs and retries. Integrations with tools like Zapier, Make and n8n connect through these webhooks plus the API and MCP, rather than a native app listing. A delivery log is visible in Settings. That is where to check whether a specific event fired and succeeded, rather than assuming from the configuration alone.
A webhook that fails silently is worse than one that fails loudly
Questions
- What is the difference between a webhook and an API integration?
- A webhook pushes data out the moment an event happens. An API is typically pulled from: the other system has to ask for data on its own schedule. Webhooks are lower latency for real-time triggers. APIs suit bulk or on-demand data retrieval.
- Does a webhook need a dedicated server to receive it?
- It needs an endpoint that can receive an HTTP request. That could be a dedicated server, a serverless function, or a middle-layer tool like Zapier or Make that turns the webhook into another action without custom code.
- What happens if the receiving endpoint is down when a webhook fires?
- It depends on the sending system. Some CRMs retry failed webhook deliveries automatically for a period. Others send once and consider it delivered whether or not it succeeded. Confirm this behaviour. A missed webhook with no retry can silently drop an event.