Wire it to your own systems
Outcomes
Push, not poll
There are two ways to learn that something happened in another system. You can ask on a timer, over and over, which is polling: wasteful, and always a little behind. Or the other system can tell you the moment it happens. That message is a webhook, and for anything time-sensitive it wins every time.
Everything so far has happened inside the platform. This is the rung where the build reaches the systems your agency actually runs on.
Send data out
You are here: Partner Center → Automations.
Inside any automation, the Send a webhook step posts to an endpoint you name. It is how a workflow reaches a system the platform has no built-in step for: a team chat, a job board, your own server. You can customize the query parameters, headers, cookies, and the JSON body.
Two facts shape what you put in it.
Send identifiers, not the data itself. The request goes over HTTPS, but the platform cannot confirm that the destination is under your team's control, so anything sensitive is safer left out. Send the record's ID, then fetch the current version over the API on your side. That also means the data your system acts on is never a stale copy.
The body is a single JSON object. Nested JSON is not supported unless you construct it yourself, so design the payload flat.
Labadd a Send a webhook step and fire it
Go to Automations → My automations → Rain delay follow-up.
Read the payload before you build on it
That payload is the contract. Everything you build on the receiving side is built to match its shape, so you confirm the shape first and write the handler second. Reading it afterward means writing the handler twice.
The step also passes data back the other way. Whatever your endpoint returns can feed the automation steps that follow it, but only if you declare it under Response body first: "Specify the data from the webhook response that should be passed to other steps." Use + Add data value and check the Expected payload preview. Without that, the response arrives and later steps cannot see it.
Start it from outside
The same idea runs in reverse. An automation built with the Triggered via API for an account trigger can be started from your own code with a single call, for one business at a time. There is a sibling for orders, and a Triggered via Zapier trigger beside them. That turns a chain of platform actions into one request from wherever your work actually starts.
To hand it data as well, fill in the trigger's Payload data section to match the keys you intend to send: "Define the structure of the data that will be passed in via the webhook." Choose the right Type for each key and later steps can use those values directly as their inputs. Skip that configuration and the call still starts the automation, but the data does not reach the steps.
There is a boundary worth knowing here, because it saves an afternoon: you can start an automation from outside, and you cannot author one from outside. Automations, AI Employees, and Vibe apps are built in the interface. The developer documentation covers the call itself.
Look at the payload sitting on webhook.site and pick the one field your own system would key on. If it is anything other than an ID, ask what happens when that value changes tomorrow.
Knowledge Check
Three quick questions on what to send, reading the payload, passing a response onward, and starting an automation from outside.