Skip to main content
Custom AI Actions let the AI call your own API during a conversation — to look up an order status, check an account balance, or trigger a workflow — instead of only answering from your knowledge base. The AI decides when to call an action based on the conversation, sends the arguments your API expects, and can read the response back to the visitor.
Plan requirement: Custom AI Actions are available on the Business plan.

​
How it works

  1. You define an action: an HTTP endpoint, its method, and the parameters the AI needs to supply (e.g. order_id).
  2. The AI sees the action as a tool it can call, with your description telling it what the action does and when to use it.
  3. During a conversation, if the AI decides the action is relevant, it calls your endpoint with the arguments it inferred from the conversation.
  4. Your API responds, and the AI uses that response to answer the visitor — or, for actions marked to require confirmation, the visitor is shown a card to approve or cancel first.

​
Creating an action

Go to Dashboard > Actions > New action. Each action has: You can have up to 20 actions per workspace.

​
Parameters

Each action can declare up to 12 parameters — the inputs the AI must supply when calling it. For each parameter you set:
  • Name — lowercase letters, digits, underscores (matches the placeholder name if used in the URL).
  • Type — string, number, or boolean.
  • Description — shown to the AI so it knows what to pass.
  • Required — whether the AI must supply a value.
  • Enum values (string parameters only) — an optional comma-separated allow-list (e.g. open, closed, pending), constraining the AI to one of those values.
Parameters that appear as a {name} placeholder in the URL are substituted into the path (URL-encoded); any remaining parameters are sent as query-string params on GET/DELETE requests, or as a JSON body on POST/PUT/PATCH.

​
Headers

  • Headers — static, non-sensitive headers sent with every request (e.g. Accept: application/json).
  • Secret headers — for API keys and tokens. Values are encrypted at rest and write-only: once saved, the dashboard only ever shows the header names you’ve configured, never the values. To change a secret, re-enter it under its name; to keep it, leave it blank. An update is a per-key merge — keys you don’t re-type are kept as-is, so partial edits never wipe secrets you didn’t touch. A “Remove all secrets” checkbox clears every secret header at once.

​
Visitor confirmation

For actions that change state (placing an order, cancelling a booking, updating a record), turn on “Ask the visitor to confirm before executing.” Instead of running the call immediately, the AI:
  1. Shows a confirmation card in the widget with the action’s display name and the arguments it plans to send.
  2. Tells the visitor to confirm or dismiss it, without claiming the action already happened.
In the widget, the visitor sees Confirm or Not now buttons. Confirming runs the call and shows a “Working on it…” status, followed by a success or failure message (a failed call offers a Dismiss button); a successful card clears itself automatically after a few seconds. Only one confirmation card can be open at a time — if the AI tries to propose a second action while one is still pending, the call is refused and the AI is told to have the visitor resolve the first one. Confirmation requests that are never acted on (e.g. the visitor closes the tab) are automatically cancelled after 15 minutes; execution requests that are confirmed but never complete are marked failed after the same window, so nothing lingers in a pending state indefinitely.

​
Execution log

Every time an action runs — whether triggered directly by the AI or via visitor confirmation — it’s recorded to that conversation’s execution log, visible to agents in the inbox sidebar under “AI Actions.” Each entry shows the action’s display name, how long ago it ran, its duration, and a status badge: success, failed, pending, executing, or cancelled. The log only surfaces status metadata — the actual request arguments and response body are never shown in this view, since they may contain third-party data your team hasn’t reviewed for the dashboard.

​
Test runs

Before relying on an action in production, use Test run from the action’s menu on the Actions page. It renders one input per declared parameter (a checkbox for booleans, a dropdown for enums, a text/number field otherwise), then fires the real HTTP call with the arguments you provide. The result shows the response status, duration, and a preview of the response body — without creating an entry in any conversation’s execution log.

​
Security guarantees

Because custom actions let the AI reach out to arbitrary URLs you configure, ReplyBubble applies several protections automatically:
  • Public HTTPS endpoints only in production. Action URLs are validated (and, at execution time, re-validated against the resolved IP addresses) to block requests to private networks, loopback addresses, link-local ranges, and cloud metadata endpoints — so an action can’t be pointed at your own infrastructure or another tenant’s. HTTP and private/internal addresses are only permitted outside production, for local testing.
  • No redirects. Responses in the 300-399 range are treated as failures rather than followed, so an action can’t be redirected to an unintended destination after validation.
  • Response size cap. Response bodies are streamed and capped at 256 KB; anything beyond that is discarded rather than buffered in full.
  • Errors never leak raw details. If a request fails (bad TLS, malformed response, a secret with a stray character breaking the HTTP client), the AI and the execution log only ever see a generic message like “Request timed out” or “Request failed to send or complete” — never the underlying exception text, which could otherwise expose configured secrets.
  • Per-turn invocation cap. The AI can call actions at most 5 times while composing a single reply, capping runaway tool use and API spend.

​
Limits summary

​
Troubleshooting