Webhook
POSTs the event as JSON to an endpoint you own. Use it to feed a SIEM, trigger automation, or bridge to a tool Willow doesn't support directly.
Webhooks are audience-independent: they post to the endpoints you select, never to people.
Add an endpoint
- Go to Security → Alerts → Channels.
- Under Destinations, select Webhook.
- Name it (e.g.
SIEM ingest) and enter the endpoint URL. - Select Add, then Test to confirm it's reachable.
Then turn Webhook on for a rule delivery and select the endpoint. A delivery with Webhook enabled but no endpoint selected is rejected when you save it.
Payload
Sent with Content-Type: application/json, timing out after 5 seconds.
{
"timestamp": "2026-09-07T10:30:00.000Z",
"type": "notification",
"event_type": "skill_guard.blocked",
"event_label": "Skill Guard · Skill blocked",
"severity": "high",
"title": "Skill blocked: Invoice Summarizer",
"message": "The *Invoice Summarizer* skill was blocked before it could run.",
"default_title": "Skill blocked: Invoice Summarizer",
"default_message": "The *Invoice Summarizer* skill was blocked before it could run.",
"action_url": "https://app.withwillow.ai/alerts?alert=…",
"metadata": {
"skill_name": "Invoice Summarizer",
"source": "Device scan",
"actor": "user@example.com",
"device": "MacBook-Pro",
"guards": "Prompt Injection Detection"
}
}
| Field | Notes |
|---|---|
event_type | Stable machine identifier. See the event list. |
severity | critical, high, medium, or low, after any rule override. |
title / message | The rendered text, including any template you configured. |
default_title / default_message | The system-generated text, ignoring templates. |
action_url | Deep link into the Willow dashboard, when available. |
metadata | Event-specific context; the keys vary by event type. |
title and message change the moment an admin edits a template. Machine consumers should read default_title / default_message, or better, event_type and metadata.
Reliability
Deliveries are best-effort and fire-and-forget: the guard decision, tool call, or scan is never blocked waiting on your endpoint.
- Requests time out after 5 seconds — respond quickly and do your processing asynchronously.
- Each endpoint on a delivery gets its own audit record, so a broken staging endpoint doesn't mark the production one failed.
- There are no retries. Combined with the rate limit, assume you may miss events and treat the alert history as the source of truth.
Hardening
Willow sends no authentication header, so anything you need must live in the URL or your own checks.
- Include a secret path segment or query token, and verify it server-side.
- Make handling idempotent — assume a delivery may arrive more than once.
- Allow outbound egress from your Willow deployment to the endpoint host.
Troubleshooting
Nothing arrives. Verify the URL and that it returns a 2xx. Use Test, which reports the status your endpoint returned.
Intermittent failures. Usually the 5-second timeout. Acknowledge immediately and process in the background.
Related
- Alert rules
- Channels
- Log delivery — for full audit-log streaming, which is a different feature from alerts