HTTP Webhook
Run an automation when an external system posts to a URL.
What it does
Exposes a URL endpoint that, when called, fires the workflow with the request's headers and body available in memory. This is the standard way to plug the AI Kit into any other system that can send HTTP — CRMs, ticketing systems, monitoring tools, custom apps.
The URL is unique per workflow and includes a shared secret, so only callers who know the secret can fire it.
What you configure
| Field | What it controls | Required | Notes |
|---|---|---|---|
| Shared key | Secret value embedded in the URL. | required | Stored as a secured value. The webhook URL is …/webhook/{workspace}/{workflow}/{key}. |
| Header memory (memory output) | Where the HTTP headers are stored. | required | Useful for authentication or routing decisions in the workflow. |
| Body memory (memory output) | Where the request body is stored. | required | This is usually what your workflow processes. |
📷 SCREENSHOT: The Webhook Trigger with the secret field and the generated URL preview displayed below it.
Example scenario
React to a new ticket. Your ticketing system can fire a webhook when a new ticket is created. Configure it to call the AI Kit webhook URL. The workflow reads the ticket from the body, summarizes it with an LLM, and posts a comment back via HTTP Request.
Recommendations
- ✅ Use a long, random shared key. Treat it as a password.
- ✅ Rotate the key periodically and immediately if you suspect exposure. Update the calling system at the same time.
- ✅ If your caller can sign requests (HMAC), still keep the shared key. Defense in depth.
- ⚠️ The endpoint returns quickly even though the workflow may take a while. Callers should not depend on the response containing the workflow's result.
- ❌ Do not embed the URL with the key in publicly accessible places (READMEs, screenshots, error messages).
What to do next
- For outgoing HTTP from inside a workflow: HTTP Request.
- For inbound mail: E-Mail Inbox.