# 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 any employee's Tools tab and the employee gets a "send" tool that POSTs JSON data to that URL on demand. Use it to trigger automations in Zapier, Make, or any system that accepts webhooks. This is for advanced users who want their employees to push data to external systems.

> 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. Stores the name, URL, and optional auth header
2. Creates a single `send` tool for that webhook
3. Assigns it to all employees (current employee enabled, others disabled)
4. At runtime, when the employee calls `send`, the platform POSTs a JSON payload to the URL
5. Returns the response status and body (truncated to 2,000 characters)

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

## Adding a Webhook

1. Open any 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")
   - **URL**: the endpoint to POST to (e.g., `https://hooks.zapier.com/hooks/catch/...`)
   - **Auth Header**: optional, if the endpoint requires authentication (e.g., `Bearer sk-...`)
6. Click **Save**

## Auto-Assignment

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

- It gets assigned to **all employees** automatically
- The employee you're configuring has it **enabled** by default
- All other employees have it **disabled** by default

## Use Cases

| Scenario | Example |
|----------|---------|
| **Trigger automations** | Notify Zapier or Make to kick off multi-step workflows |
| **CI/CD pipelines** | Start builds or deployments when a task completes |
| **CRM updates** | Push lead or deal updates to HubSpot, Salesforce, or Pipedrive |
| **Team alerts** | Post messages to a Slack channel via Incoming Webhooks |
| **Event logging** | Send structured events to a logging or analytics service |

## 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.

### Remove

Delete the card to archive the webhook. It will be removed from all employees.

### Tool Rules

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

## Example Payload

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

```json
{
  "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
- **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

- **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. Some services expect `Bearer token`, others expect a custom header format. Match exactly what the endpoint requires
- **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: 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.