Webhooks
Your URL. Signed. Thirteen events.
When neither connector nor Zapier is the answer, paste an HTTPS endpoint and choose the events. Every delivery is signed, retried, and recorded where you can see what happened.
You already have the system. You just need it told.
The ERP, the internal dashboard, the thing the last developer wrote — plenty of teams do not need another SaaS in the chain, only a POST when a conversation starts or a deal moves. Polling an API every minute to discover that is work nobody should have to do.
Thirteen events, eight on by default
New conversation, label applied, contact updated, deal created, updated and deleted, ticket created and updated are on. Every message, delivery status, conversation changed and the two follow-up events are off until you choose them.
Signed, so you can trust it
Each delivery carries an HMAC-SHA256 signature over the body and a timestamp header. Verify both and you know the request came from your workspace and is not a replay.
The destination is checked on every send
The URL is resolved to an IP and that IP is tested against every private range before a byte leaves — at send time, not only when you saved it, because a check that runs once is decorative against DNS rebinding.
Retries, and a log of what happened
A failed delivery is retried, and every attempt is recorded with its status, response code and error. When a receiver has been down all morning you can see that rather than guess it.
A filter per endpoint
Restrict an endpoint to conversations carrying particular labels, so the endpoint your warehouse system listens on never hears about a sales thread.
What crosses over
- The event, with the conversation and the contact attached — including the number, which is what a CRM matches on.
- Deals, tickets and follow-ups passed through whole, so a field added to a deal appears without anything being rewired.
- Only what the workspace can see. A webhook has no user, so it gets the one visibility tier defined without a person in it.
What never does
- Internal notes. Notes carry their own direction and the dispatcher filters to real inbound and outbound messages.
- Private conversations, or ones under a number somebody excluded. Structurally out of reach, not filtered on the way out.
- An address on your internal network. A destination that resolves into a private range is refused, which is what stops a webhook becoming a route to your cloud metadata service.
Integrations are a Pro capability. Starter does not include HubSpot, Pipedrive, Zapier, webhooks or the API.
When you would use it
- Telling an ERP that a new customer has written in for the first time.
- Raising a job in your own system the moment a ticket is created.
- Feeding an internal dashboard without giving it credentials to the whole inbox.
- Reacting to a deal moving to won, in a system Zapier does not reach.
What this leans on
Questions people ask
Which plan is this on?
Pro. Integrations — HubSpot, Pipedrive, Zapier, webhooks and the API — are a Pro capability, and Starter does not include them.
How do I verify a delivery?
Recompute the HMAC-SHA256 over the raw body with your endpoint’s secret and compare it to the signature header, in constant time. Check the timestamp too — that is what makes a captured request useless later.
What happens if my endpoint is down?
The delivery is retried, and the failures are recorded against the endpoint. A run of failures in a row is surfaced rather than left for you to discover, so an endpoint that has quietly stopped working does not stay quiet.
Can a webhook see a private chat?
No. A webhook is a URL, not a person, so it is given the only visibility tier that is defined without a user in it — the workspace tier. A conversation somebody marked private is not something the dispatcher can reach.