Connections

Updated 25 October 2026

Connect the services your business runs on, and your chatbot and its workflows use them: they look up an order, call your own API or act through your tool server, always for the customer they are talking to.

Everything here is set up under Tools in your dashboard. Once a service is connected, the chatbot uses it when a conversation needs it, and a workflow's Tool Call step can name any of its tools. Every call shows in the conversation log.

Your API

A custom action is one of your own HTTP endpoints, described once so the model knows when to call it: looking up an order, creating a ticket, booking a slot. The app makes the call for the chatbot, so your API key never reaches the model or the visitor.

1. Under Tools, tap + on the Your API tile. The Custom actions card opens with a new action to fill in; for more later, press Add action.
2. Give it a name, such as get_order_status, and a description for the model that says what it does and when to use it.
3. Choose the method and enter the URL. A {param} in the path is filled from the parameters; the others go in the query for GET, or the JSON body.
4. List the parameters, one per line: name, type, required or optional, and a description, such as order_id, string, required, The order number.
5. Add the headers your API needs, such as Authorization: Bearer …. A saved value shows as dots from then on and is never sent back to your browser.
6. Save, then press Test to call it with sample values and see exactly what the model would receive.

Each call tells your endpoint who it is for: the person in X-User-Id and the conversation in X-Session-Id, unless you set those headers yourself. On your website the person is ChatFrom's id for the visitor (visitor: and a browser id), not your own user; a test sends your ChatFrom user id. The chatbot fills in the parameters, and a customer can talk it into any value, so if your endpoint reads or changes one customer's data, check there that this person may. To act for your signed-in users, use your tool server.

Your tool server

If your product runs an MCP server, the chatbot can use its tools directly. Under Tools, tap + on the MCP server tile. In the MCP servers card that opens, add the server's name and address, and any headers it needs, such as a token. Press Find tools and tick the tools the chatbot may use, up to 50; nothing else on the server is shown to the model. A token is stored encrypted and shows as dots once saved. The address must be on the public internet: ChatFrom checks where it points when you save it, and again as conversations go on, and leaves the server out while it points into a private network.

Tick Send the site's signed-in user token to this server for a server your own site runs. When the page embedding the widget passes a token it signed for its user, your server receives it as X-User-Id and can act on that account and no other. In the chat apps, users link their account once to get the same, as Channels explains.

Zapier

Zapier reaches thousands of apps, such as Gmail, Slack or Airtable, through an MCP server of its own, so the chatbot can draft an email or post a message with the actions you choose.

1. At mcp.zapier.com, add an MCP server, choose Other as the client, and set it to Managed mode. Add the actions the chatbot may take, such as "Send a Slack message".
2. In the server's settings, generate an API token and copy it. Zapier shows it only once.
3. Under Tools, add an MCP server named zapier with the address https://mcp.zapier.com/api/v1/connect, and the header Authorization: Bearer followed by your token.
4. Press Find tools, tick the actions the chatbot may use, and save.

Use Managed mode. In Agentic mode the AI could add actions of its own during a conversation, which a chatbot that talks to the public should not do. The chatbot is only ever offered the actions you ticked, and each one it runs uses two tasks from your Zapier plan.

Signed-in users on your site

For the chatbot to act for the person signed in to your site, the page gives the widget a token your server signed for that user, on the same script tag you copied from Deploy.

<script src="https://chatfrom.io/w.js"
  data-bot="<your chatbot's id>"
  data-user-token="<the token your server signed for this user>"
  defer></script>

• What the token may be: up to 1,024 letters, digits and . _ ~ -, such as a JWT or a base64url string. A token with any other character, such as the +, / or = of plain base64, is dropped, as if the page had given none.
• Where it goes: the widget hands it to the chat by postMessage, never in an address, so it stays out of request logs. It reaches only the tool servers you ticked for it, as X-User-Id: not the model, your other tools or the conversation log. ChatFrom never reads it; your server checks it and acts on that account alone.
• A page open for hours: call window.ChatFrom.setUserToken(token) with a fresh token before the old one expires, and with null when the user signs out. Every chatbot on the page takes it.
• A single-page app: on a page that should not have the chatbot, window.ChatFrom.remove() takes the widget off, or window.ChatFrom.remove(id) one chatbot of several. Adding the script tag again brings it back.

// A fresh token before the old one expires, or null once the user signs out.
window.ChatFrom.setUserToken(token);

// A page of a single-page app that should not have the chatbot.
window.ChatFrom.remove();

Another service

Anything with an API is reached through your API, your tool server or Zapier. Need a service built in? Tell us.