Give An Employee Its Own Webhook To Trigger

Details

Point an employee at any outbound webhook, your own automation, a Zapier or Make scenario, an internal service, anything that accepts an HTTP call, and it becomes a tool the employee can use on its own during a task, not something you fire manually from a dashboard. Set it up once with a URL and an optional auth header. Each webhook becomes exactly one send tool scoped to that URL and attached to the team, so add three and an employee sees three separate send tools and picks the right one for the task. You can enable or disable one for a single employee, overriding the team. At runtime the call is a POST with a JSON body, your auth header passed through as you gave it, and the employee waits up to 30 seconds. It gets back the status code and a slice of the response, enough to know the call landed. If it fails, on a bad URL, a timeout, or a blocked address, the employee tells you the webhook failed rather than quietly treating the task as done. By default an outgoing call pauses and shows you the exact payload before it goes, the same as any other action that reaches outside the platform. Turn that off for a specific webhook once you trust it. Two honest limits. The URL is checked when you save it and rejected if it does not answer, and calls to internal, private, or cloud metadata addresses are refused, with redirects not followed, so a public-looking URL cannot hop somewhere internal. And it is one-way by design: this triggers something, it does not query it. Having an employee read data back from an API and reason over it is a separate capability.

What changed

• Give an employee a webhook it can trigger on its own, mid-task
• Works with Zapier, Make, or any endpoint that accepts an HTTP POST
• Each webhook becomes one send tool, switchable per employee
• The payload waits for your approval until you turn that off for that webhook
• One-way by design: it triggers something, it does not read data back