Guide
Webhook workflow automation: start a crew from an HTTP call
A webhook is a way for another system to start the workflow you already deployed. It is not a second product, and it does not skip the approval on a send.
Three ways a run starts
Someone can start a run by hand. A schedule can start it at the time you set, with a time zone. A webhook URL can start it when another system sends a request. Integration events, such as a new Gmail message that matches a search, are a fourth start when that connector is on the crew.
What the webhook receives
The product generates a URL for that crew. Treat the URL as a secret. The run can read the request body, the headers, and the query string. The next steps are the ones on the deployed workflow: a model step if you need a draft or a classification, then a tool step for a specific action.
If that action sends email, sends a Telegram message, or creates or deletes a calendar event, the run waits. The caller does not get to mark the send as already approved.
When a webhook is the wrong trigger
Use a schedule when the work should happen every morning whether or not another system calls you. Use a manual run when a person should decide that this particular input is worth processing. Use the Gmail or Telegram trigger when the event already lives in that account and you do not want to operate your own bridge.
Questions
Does a failed webhook retry itself?
No. If the run fails, the history keeps the step and the error. Fix the workflow or the connection, then run it again. There is no automatic retry loop.