Send Outbound Webhooks

Your employees can POST JSON to any external URL during work. This lets them notify external systems, trigger workflows, or push data to third-party services in real time, without any custom integration.

TL;DR

Add a webhook URL in an employee's Tools tab and it gets a "send" tool that POSTs JSON data to that URL on demand. Every send pauses for your approval by default, so nothing leaves your system unattended. Use it to trigger Zapier, Make, or any system that accepts webhooks.

This page covers outbound webhooks (your employee sends data out). For inbound webhooks (external systems trigger your employee), see Listen to Webhooks in the Channels and APIs section.

How It Works

When you add a webhook, the platform:

1. Checks that the URL is reachable (a quick HEAD request) before saving it
2. Stores the name, URL, and optional auth header
3. Creates a single send tool for that webhook
4. Attaches it to the employee's team, so every teammate on that team inherits it
5. At runtime, when an employee calls send, the platform POSTs a JSON payload to the URL
6. Returns the response status and body (truncated to 2,000 characters)

Each webhook becomes one tool. If you add 3 webhooks, an employee on that team sees 3 send tools, each targeting a different URL.

By default, sending a webhook pauses the employee's work and asks for your approval first, the same way a payment or an outbound email would. You review the payload and approve or reject it before it goes out. A team can turn this off for a specific webhook if you want it to fire without asking.

Adding a Webhook

1. Open an employee's Tools tab
2. Scroll to the Integrations section
3. Find the Webhooks group card and click the "Add Webhook" pill button
4. A drawer slides open with the configuration form
5. Fill in:
   • Name: a label you'll recognize (e.g., "Zapier Hook", "CI Pipeline", "Slack Alert")
   • Webhook URL: the endpoint to POST to (e.g., https://hooks.zapier.com/hooks/catch/...)
   • Auth Header (optional): sent as the request's Authorization header, e.g. Bearer sk-...
6. Click Add Webhook

The platform checks the URL before saving. If it can't be reached, or it resolves to an internal or private address, the request is rejected and you'll see an error explaining why.

Auto-Assignment

Webhooks follow the same pattern as MCP servers and A2A agents. When you add a webhook:

• It's attached to the team of the employee you were configuring
• Every employee on that team inherits it, enabled by default
• Employees on other teams don't get it unless you add the same webhook again from one of their Tools tabs
• You can still enable or disable it per employee from that employee's Tools tab, overriding the team default

Use Cases

Managing Webhooks

Enable/Disable

Toggle the switch on the webhook card to enable or disable it for a specific employee. Disabled webhooks won't be available at runtime.

Health Check

Click Health Check on the webhook card to re-verify the endpoint is still reachable. This updates the card's health status without changing anything else.

Remove

Delete the card to archive the webhook. It's removed from every employee it was attached to.

Tool Rules

Add custom instructions in the Tool Rules (optional) field on the card. These get appended to the tool's description at runtime, so the employee follows your guidance when deciding what to send and when.

Approval

Sending data to an outside URL is treated as an irreversible action, the same category as a payment or a real outreach email. Unless a team has explicitly turned approval off for this webhook, every send call pauses and shows you the exact payload the employee is about to POST. You approve or reject it before anything is sent. This is independent of any instructions you put in Tool Rules, it's a hard gate the employee's own judgment can't skip.

Example Payload

When an employee calls a webhook's send tool, it POSTs a JSON body it constructs from context. For example, a webhook to Zapier might send:

{
  "event": "task_completed",
  "customer_name": "Acme Corp",
  "summary": "Drafted Q1 report and sent to stakeholders",
  "completed_at": "2026-03-15T14:30:00Z"
}

The employee decides the payload structure based on what it knows and what makes sense for the target system. Use Tool Rules to constrain the shape, e.g., "Always include an event field and a timestamp field. Never include internal IDs."

Good to Know

• One-way communication. Each send is an independent HTTP POST. The employee sends data out but doesn't maintain an ongoing connection
• Truncated response. The response body from the endpoint is capped at 2,000 characters to keep things efficient
• 30-second timeout. If the endpoint doesn't respond within 30 seconds, the call fails and the employee sees an error
• JSON only. The payload is always application/json. The employee decides the payload structure based on context
• Authorization header only. Whatever you enter in Auth Header is sent verbatim as the Authorization header. There's currently no way to send a differently named custom header
• Internal URLs are blocked. The platform won't send to localhost, private IP ranges, or cloud metadata addresses, on the add step and on every send
• Same billing. Webhook calls are part of the employee's normal workflow. Credits are consumed for the LLM reasoning, not for the HTTP call itself
• Error handling. If the endpoint returns a non-2xx status or is unreachable, the employee sees the error and can retry or work around it

Troubleshooting

• "Webhook endpoint unreachable" when adding. The platform HEAD-checks the URL before saving. Confirm it's correct, publicly reachable, and not returning a 5xx error
• Endpoint not receiving requests. Verify the URL is correct and publicly reachable. The platform sends requests from its cloud infrastructure, not your local network
• Auth failures (401/403). Check the Auth Header value. It's always sent as Authorization: <value>, so include the scheme your endpoint expects, e.g. Bearer sk-...
• Timeout errors. The platform waits 30 seconds for a response. If the endpoint is slow, optimize it or use an async endpoint that returns 200 immediately
• Unexpected payload shape. The employee decides the JSON structure based on context. Use Tool Rules to enforce a specific schema

Frequently Asked Questions

Q: Can the employee receive data back from the webhook? A: The employee sees the HTTP response status and up to 2,000 characters of the response body. This is useful for confirmation messages, but webhooks are primarily designed for pushing data out. For two-way communication, consider MCP or A2A instead.

Q: Does every webhook call need my approval? A: By default, yes. A send call pauses and shows you the payload before it goes out, the same as an outbound email. A team can turn this off for a specific webhook so it fires without asking.

Q: Can I control what data the employee sends? A: Yes. Use Tool Rules to specify the exact JSON structure you want. For example: "Always include event, timestamp, and summary fields. Never include employee IDs or internal data."

Q: What happens if the webhook endpoint is down? A: The employee gets an error and can retry. There is no automatic retry or queuing. If reliability is critical, use an intermediary service like Zapier that handles retries on its end.

Q: Can I add multiple webhooks for different purposes? A: Yes. Each webhook becomes a separate tool. You can add one for Zapier, another for Slack alerts, and a third for your internal logging. The employee picks the right one based on context and your Tool Rules.

Q: How is this different from connecting Slack or other apps directly? A: App integrations (like connecting Slack via OAuth) give the employee full access to that app's features: read channels, post messages, search history. A webhook is simpler and more limited. It just POSTs data to a URL. Use webhooks when you need a lightweight connection or when the target system only accepts webhooks.