Webhooks and platform events
Outcomes
Push, not poll
There are two ways to find out when something happens in another system. You can ask on a timer, over and over, which is called polling. It is wasteful, and it is always a little behind. Or the other system can tell you the instant it happens. That message is a webhook.
A webhook is a small message one system sends another the moment an event occurs. For anything time-sensitive, a lead arriving, an order changing, push beats poll every time.
Send data out: the outbound webhook step
Inside an automation, a webhook step sends data out to any endpoint you name. It is how a workflow reaches a system the platform has no built-in step for, the way a follow-up automation might ping the team's chat or trigger the next call. It posts a small package of JSON, a plain and structured text format, to a URL you control. Three habits keep it working on the first try:
- Put your data in the body of the request as JSON, not in the headers. Sending it as headers is the single most common mistake.
- Send values as text. A number sent as a raw number can error; send it as a string.
- It carries data, not files. There are no attachments.
Before you wire anything downstream, test-fire the step and read exactly what arrives. That payload is the contract everything after it depends on, so you confirm its shape before you build on it, not after.
Receive events: inbound triggers
The same idea runs in reverse. An automation can start from an inbound webhook: the platform gives the trigger its own unique URL, and a POST to that URL starts the workflow with whatever data you send. An automation can also be started by an API call, or by a glue tool like Zapier sitting in front of it. However it starts, the automation carries the work from there.
Reacting to things that happen, when you productize
When you build a product that others resell, you will want it to react to things happening across every account that uses it: a purchase, a new account, a change to a user or a customer. The pattern is the same one you just used — something happens, and the platform pushes it to you, instead of your code asking over and over whether anything changed.
The vocabulary you will actually see in the product and the docs is "trigger" and "automation" for the things you build, and "webhook" for the delivery mechanism. Search for those.
Create an outbound webhook step in a test automation and point it at a free request-bin URL, like Webhook.site. Test-fire it and read the payload that lands. Seeing the exact shape of what the platform sends is the whole game; everything you build downstream is built to match it.
Knowledge Check
Three quick questions on push versus poll, the outbound step, and starting an automation from outside.