What are Call actions?

What it is

A Call Action is something your chatbot is allowed to do during a conversation, on top of answering from knowledge. Show a button, escalate to a person, email your team, save a contact, call your API.

The important word is allowed. You build a library of actions; the chatbot chooses which one, if any, fits the moment. It can only ever use actions you created and switched on. It cannot invent one, and it cannot reach anything you did not configure.

The tab describes it as: "Let your chatbot trigger actions during a conversation — show a button, hand off to a human, or notify your team."

When you would use it

Once your chatbot answers questions well and you want it to be useful rather than only informative:

• The visitor asks for a person and nobody finds out.
• Every conversation ends at "contact us at…" instead of actually booking, tracking, or ticketing.
• Your team is copying details out of transcripts into a CRM by hand.
• People ask about live data — an order, a shipment, a price — that no static knowledge base can hold.

Set up knowledge first. A chatbot with actions but no knowledge is a phone tree. See Knowledge overview.

Where to find it

Open Dashboard → Chatbots → your chatbot → Actions.

Settings → Instructions is where you set the chatbot's standing rules — see Write instructions. Instructions shape how it answers; actions decide what it can do.

The six types

Type	What it does	Sends anything outward?	Article
Button	Shows a call-to-action button under the reply	No	Show buttons and quick replies
Human handoff	Flags the conversation and emails your team	Email	Hand off to a human
Notify team	Emails your team a summary, silently	Email	Notify your team
Collect info	Gathers contact details and saves them to Customers	No	Collect visitor details
Custom API	Calls an API you configure and can use the answer	HTTP request	HTTP connectors
MCP server	Connects a remote MCP server's tools	HTTP request	MCP connector availability

There is one behavioural split worth understanding, because it explains a lot of the product's behaviour: Custom API and MCP server bring data back into the conversation, so the chatbot can read the result and answer with it. The other four are one-way side effects — the chatbot gets a short confirmation that it worked and carries on.

For the named-integration shortcuts built on top of Custom API — Cal.com, Zendesk, Slack, Shopify, and around two dozen more — see Use a preset and the Call action preset reference.

What a Call Action is not

• Not a channel. Channels are where people talk to your chatbot — the website widget, WhatsApp, the hosted page. Actions are what it may do once they are talking. See Channels overview.
• Not a workflow builder. There is no canvas, no branching, no "if this then that". Each action is a single capability, and the model decides when to reach for it.
• Not something you run by hand. You cannot fire an action from the dashboard. It runs only inside a conversation, when the chatbot decides it fits.
• Not an automation schedule. Nothing runs on a timer. No conversation, no action.

How the chatbot decides to use one

1. Your enabled actions are offered to the chatbot's AI model as available tools, along with each one's When should the AI use this? description.
2. The model reads the visitor's message and decides whether any tool fits.
3. If one does, it works out the values to pass — the order number, the email address, the summary — from the conversation.
4. The action runs, and the outcome is recorded as a run.
5. The reply is written with the outcome in hand.

Two consequences follow from this, and they explain most surprises:

The description is the control surface. It is not a label; it is the instruction the model reads when choosing. A vague description makes an unpredictable chatbot. The tab says as much: how reliably actions fire depends on the model's tool-calling support and, most of all, a clear "when to use this" description.

The model must support tool calling. If your chatbot is on a model that cannot call tools, the tab shows "Actions are temporarily unavailable" and nothing fires however well you configure it. See Chatbot AI settings.

Safety rails you get by default

You are letting an AI model act on your behalf, so the product constrains it in ways worth knowing:

• Only enabled actions exist. A disabled action is invisible to the model.
• Confirmation for anything destructive. Actions marked Requires confirmation — and any Custom API action that changes data — need the visitor to confirm on a following message. The chatbot cannot confirm on its own behalf within one reply, so text it reads from a page or an API cannot talk it into acting.
• Fixed destinations. For a Custom API action you fix the host. Values from the conversation fill the path, query, and body only; they can never redirect the request somewhere else.
• No private networks. Requests to internal or private addresses are refused and logged as Blocked destination.
• Bounded per turn and per visitor. A single reply can only run a few actions, each outbound call has a few seconds to answer, one visitor session has a cap on how many runs it may trigger, and each chatbot has a daily ceiling. An endpoint that keeps failing is paused briefly rather than hammered.
• Write-only secrets. Credentials you paste are never shown back and never appear in run logs.
• Everything is recorded. Each attempt is a run with a status and a client-safe error reason. See Call Action history.

What you will see

The tab opens with four counters — Actions, Enabled, Total runs, and Success rate — above a grid of action cards. Each card shows its type icon, an Enabled or Disabled badge, run count, and last run, with controls to edit, view logs, enable or disable, and delete.

With nothing configured yet you get an empty state offering the type picker and the template gallery directly, so a first action is a couple of clicks away.

Limits and plan notes

• Your plan caps how many actions can be enabled per chatbot: Free 0, Starter 3, Standard 8, Pro 12, Agency 20. On Free the tab explains that Call Actions are not available on your plan. See Plans and what you get.
• Disabled actions do not count against that cap, though a chatbot cannot hold an unlimited number of them in total.
• You need permission to manage actions on the chatbot. See Roles and permissions.
• MCP is availability-dependent and off by default. Treat it as unavailable unless you have seen it work on your own workspace. See MCP connector availability.
• Actions run on every surface the chatbot is live on — the website widget, the hosted page, and connected messaging channels — once the chatbot is active.
• Running an action does not cost a separate credit. The reply that triggered it spends message credits at the chatbot's model rate, like any other. See Message credits.

Common problems

The library is empty and Create is locked.

You are on Free, which includes no enabled actions, or you are at your plan's cap. Disable one you do not need, or upgrade. See Upgrade or downgrade.

The chatbot never calls my action.

Four things must all be true: the action is Enabled, the chatbot is active, the AI model supports tool calling, and the description matches how visitors phrase the request. The Test tab isolates the last one in a single run.

It fired once and then stopped for that visitor.

Per-session caps exist to stop one conversation running actions indefinitely. That is working as intended; a normal conversation never reaches them.

Something ran that I did not expect.

Open the run log and read the arguments the model passed. Nine times out of ten the description was broad enough to match a question you had not thought of. Narrow it, and add a clause naming what the action should not be used for.

Can I stop everything quickly?

Disable the action, or pause the chatbot. Both take effect on the next turn.