Let the agent do things mid-conversation, like looking up an order or calling your own API, with secrets, approvals, a test bench and a run log.
AI Actions let the agent take an action during a chat instead of just answering. It can look up an order, find a contact in your CRM, or call your own API and use the result in its reply. There is no trigger to configure: the model decides when to run an action based on the conversation. You decide what actions exist and what they are allowed to do.
Open Capabilities, then AI Actions.
AI Actions are available on Growth and above, with a monthly cap on action calls. Free and Starter do not include them. See Plans.
Two lanes
Connected apps
Ready-made actions for services we support — a Shopify or WooCommerce order lookup, a HubSpot contact. You connect the app once for the whole workspace (see Connections), then switch on the individual actions this agent should have.
Each app is one card, with its actions as rows inside it. If an app is disconnected while some of its actions are still switched on, the page says so: the agent keeps offering them and the call will fail until you reconnect.
Custom actions
A custom action calls any HTTP API you point it at. Open one and you get its whole story on a single page: what it does, what the model sees, the request, the answer, a test bench, and its run log.
Starting an action
You do not start from a blank form.
- Templates fill in the shape of a common action — look up an order, check a subscription, open a ticket, verify a licence key, check stock — and leave your host and your key to you.
- Import from cURL takes a command you already have working, from a vendor's docs or your terminal, and fills in the method, URL, headers and body. A header that looks like a credential is turned into a
{{secret.NAME}}reference rather than being stored in the clear. - Start from scratch if you know exactly what you want.
A new action is created switched off, so nothing reaches visitors until you have run it and turned it on.
What the AI sees
Every action's page shows the exact tool definition we hand the model: the name, the description and the parameter schema. That is the whole contract — the model reads only the description to decide when to call — so if an action never seems to fire, this is where to look.
It also shows what the model does not get. The URL, the headers and your secrets never leave our server.
Names are slugified for the tools API, so Look up order becomes look_up_order. If two actions would end up with the same name we tell you while you type.
Inserting values
{parameter_name}inserts a value the model collected — the parameters you declared.{{visitor.name}},{{visitor.email}},{{visitor.phone}},{{visitor.page_url}},{{visitor.locale}}and{{visitor.timezone}}insert what the visitor has already told this conversation, so the agent does not have to ask twice.{{secret.NAME}}inserts a stored secret, in headers only.
Values are escaped for wherever they land: percent-encoded in a URL, escaped for the body's content type. A customer called O'Brien cannot break the request.
Visitor details are supplied by the visitor and are not verified. They are fine for personalising a request — never use one to decide what somebody is allowed to see.
Secrets
APIs need keys, and you should never paste a key into a prompt. Store them as secrets in workspace settings, then reference them in an action's headers as {{secret.NAME}}. Secrets are encrypted, only ever used in request headers, and are stripped from anything we store. See Workspace settings.
The test bench
Run the action against its real endpoint with sample inputs. Nothing is saved and no usage is counted.
Before it fires, the bench shows the request we will send — the substituted URL, the real body, and the headers with secret values masked. You can copy it as a cURL command to hand to whoever owns the API.
Choosing what comes back
By default the whole response goes to the model. On a chatty API that is mostly fields nobody reads.
After a successful test you can pick exactly which fields to send, straight off the real response. If a field later disappears from the API we send the whole body rather than sending the model nothing.
Approvals
Some actions should not run without a human saying yes, like issuing a large discount. Mark an action as requiring approval, and when the agent wants to run it, the request lands in your Inbox as a card. A teammate approves or denies it, and the visitor waits for the result.
The run log
Every run appears on the action's page: what the model sent, what came back, the HTTP status, how long it took, and the error if it failed. Test runs are marked as such.
Secrets never appear there — they are injected into headers server-side and stripped from anything we store.
Usage
Action runs count against your plan's monthly cap. Both the Capabilities page and the AI Actions page show the same usage meter, and each action's row carries its last seven days of calls and success rate.