Most of the knowledge base teaches the assistant to answer. An action lets it do something in another system: create a support ticket, add a lead to your CRM, kick off a Zapier automation, hit your own endpoint. The assistant decides when to use it from the conversation, fills in the details, and — for anything that writes data — the visitor confirms before it runs.
A webhook action is the simplest kind: a name, two short descriptions, a URL, and the arguments to send. Point it at a Zapier / Make / n8n catch hook and the assistant can trigger any automation those tools support.
Set them up under Knowledge → Actions. Available on every plan.
What kinds of things can an action do?
An action reaches out to another system and makes something happen. For example:
- Create a support ticket in Zendesk / Freshdesk
- Add the visitor as a lead in HubSpot or a Google Sheet
- Book a demo or callback on your calendar
- Post a message to a Slack / Teams channel
- Trigger any Zapier / Make / n8n automation — which covers thousands of apps
If you can hit it with an HTTP request, the assistant can do it.
How do I add a webhook action?
- Knowledge → Actions → Add webhook action.
- Name it — a short label, e.g. Create support ticket.
- Fill in the two descriptions. They do different jobs:
- Description — what the action is for, in your own words ("Creates a Zendesk ticket for issues we can't resolve in chat"). This is for your team — it's shown in the dashboard and is never sent to the AI.
- Instructions for the AI — when and how the assistant should use it ("Use this when the visitor reports a problem we can't resolve in chat. Pass a short subject and their email."). This is what the model reads, so be specific — it's the only guidance it gets.
- Choose the method and URL — where the action posts. A Zapier catch hook
looks like
https://hooks.zapier.com/hooks/catch/…. The URL must start withhttp://orhttps://. - Add auth headers if the endpoint needs them — one per line, as
Header-Name: value(e.g.Authorization: Bearer abc123). - Add arguments. Each argument becomes a field of the JSON body the assistant posts, and the AI fills it in from the conversation. Give each a name and a short description; mark the ones that must be present as required.
- Leave Enabled ticked so the assistant can use it, and save.
That's it — there's no "sync" step. The action is ready as soon as you save.
Why two descriptions?
They're written for different readers. The Description is a note to your teammates so anyone looking at the list knows what the action does. The Instructions for the AI are a prompt to the model — phrase them as guidance ("use this when…"), not as a label. Keeping them separate means you can describe the action plainly for people without muddying the instruction the AI depends on.
How does the confirmation step work?
Because an action changes data, the assistant does not fire it silently. When it decides to run one, the visitor sees a small card summarising what's about to happen — "Create a support ticket" — with Confirm and Cancel buttons. Nothing is sent until the visitor clicks Confirm. If they cancel, the assistant simply carries on.
This is the same gate used by live tools that write data, and it's on by default for every action.
Can I skip the confirmation for a low-risk action?
Yes — untick Ask the visitor to confirm before running on the action. Then it runs the moment the assistant calls it, with no prompt.
Only do this for genuinely low-risk actions — logging an event, notifying your team, subscribing someone to a newsletter. A waived action will run automatically, including when the AI is on autopilot with no human watching. Anything that charges money, cancels something, or is hard to undo should keep its confirmation.
How do I test one before trusting it?
Use Send test in the action editor. It POSTs a real request to your URL with
placeholder values for each argument (e.g. "[test subject]"), so you can confirm
the destination — a Zapier catch hook, your endpoint — actually receives the call
and maps the fields. It reports back whether the endpoint accepted it and shows
the response. Nothing is saved, so you can iterate on the URL and arguments before
committing.
To see what happened later, open Action history on the Actions tab: a lasting record of every action the chatbot ran — time, action, status, error detail, and latency, most recent first. Failures stay here for review, so it's the first place to look if an action didn't do what you expected.
Can I point an action at an internal address?
No. For everyone's safety, action URLs must resolve to a public address. URLs
pointing at internal or private addresses (loopback, 10.x/192.168.x, cloud
metadata) are rejected when you save, and blocked again at call time. If you need
the chatbot to reach an internal system, put a public endpoint (or a Zapier/Make
hook) in front of it.
Can visitors trigger an action with a button?
Yes. A chip on an engagement campaign can be set to Run an action, turning it into a one-click button in the chat bubble — "Book a demo", "Get a callback". The same confirmation rule applies: unless you've waived it, the visitor still confirms before the action runs. The button only sends the action you configured — a visitor can't change which action runs or what it sends.
What about actions that only read data?
Those aren't actions in this sense — they're look-ups, and they belong in Live tools (MCP and OpenAPI). Read-only look-ups run automatically while the assistant drafts a reply; only data-changing calls get the confirmation treatment described here.
Is this safe?
The assistant can only call actions you created and enabled, pointed at URLs you set. Visitor text never chooses the destination — only the values inside the arguments you defined. Writes are confirmed unless you deliberately waive them. And every call is recorded in the diagnostics feed, so there's always a trail of what ran.