Integrations: overview
An integration is a saved connection to an external service: the server address, the login and the secret, stored in the workspace rather than in the graph. A node in a workflow only references such a connection; no token and no password lives inside the node.
The split buys three things. Secrets are stored encrypted in a separate column and never travel outward: the connection list shows only which secret slots are filled, not their values. The same mailbox or CRM portal is reused by a dozen workflows — a password change happens in one place. And a graph can be exported, shown to a colleague or handed to the assistant: all it carries is a connection id.
Where they are created
Settings → Integrations. The list of existing connections is on the left, the form of the selected one on the right. The Add integration button opens the kind picker — the kind is chosen once and cannot be changed afterwards, because it decides both the set of fields and which nodes will offer this connection in their dropdown.
Settings
Integrations
Model routers, LLM providers and external service connections.
| Name | Type | Secrets |
|---|---|---|
| Support mailbox | password stored | |
| amoCRM sales | amoCRM | token stored |
| Shop bot | Telegram bot | token stored |
| Staff calendar | CalDAV | password missing |
A secret field behaves unlike an ordinary one while editing: an empty value means “keep the current one”, not “erase it”. That is how the form can be saved without retyping the password — and how the server never hands the secret back to the browser.
Twelve kinds of connection
| Kind | What it stores | Who uses it |
|---|---|---|
| IMAP/POP3 and SMTP hosts, ports, login, password | the mail nodes | |
| WebDAV | base URL, login, password, timeout | external file storage |
| CalDAV | base URL, login, password, calendar discovery mode | the calendar nodes |
| MCP | server URL, auth type and token, operation mode | the mcp_tool node |
| OpenAI-compatible provider | base URL, key, list of models and their purpose | model, embedding and rerank nodes |
| Telegram bot | bot token, bot username | the Telegram channel and its nodes |
| Model fallback chain | model order and switch conditions; no secrets of its own | the model node |
| OpenRouter (media) | API key | speech-to-text, speech and image nodes |
| Bitrix24 | incoming webhook URL, optionally the portal domain | the bitrix24_rest_call node |
| amoCRM | account subdomain and long-lived token | the amocrm_rest_call node |
| VK | access token, API version | the vk_send_message node |
| VK Teams | bot token, optionally the API base URL | the vk_teams_send_message node |
That is how many kinds the platform knows. The create dialog offers eleven of them: the Type dropdown lists everything except OpenRouter (media) — bringing your own media key is not exposed to users yet, so the kind is hidden both from the form and from the connection picker on the media nodes. The kind itself works: an already-created connection of that kind still shows up in the list and still runs.
Not every kind can be checked
The Check connection button appears for exactly three kinds — Email, WebDAV and CalDAV. That is a deliberate boundary rather than an unfinished feature: the other connections are HTTP APIs that answer the very first call with a readable provider error (“invalid token”, “no permission”), so a separate button would add a surface without adding a diagnosis. Mail and DAV, by contrast, fail silently: nothing dials the server until a workflow runs, so a typo in the SMTP host or an account password used instead of an app password surfaces days later as a failed run.
Things worth knowing about the check itself:
- it runs per leg, not per connection: an email connection is two independent sessions (mailbox and submission) with different hosts and ports, so the answer can be “IMAP ok, SMTP auth failed” — exactly the diagnosis the form otherwise cannot give;
- it checks the saved version, not what you have just typed into the form;
- its budget is twenty seconds, after which it reports that the server did not answer. That is deliberate: the check holds a database connection for the length of the request, and a long timeout across a handful of stalled hosts would drain the pool of the whole API;
- the error text comes from the server verbatim, but every secret value is stripped out of it — a chatty mail server echoing the login line back must not turn the check into a way to read the password.
How a node gets its connection
There are two ways, and they coexist.
A separate configuration node. You place a <service>_config node on the canvas
(telegram_config, email_config, caldav_config, amocrm_config and so on), pick the
saved connection inside it, and run its output into the <service>_config port of the
working node with a data wire. The pattern is the same as for models: configuration is
a separate node attached from the side that does not affect execution order. The wire
differs, though: models use link_llm, integrations use a plain data edge (see
Wires).
- Execute + Data
- Data
A picker on the node itself. Integration action nodes carry a connection picker in their own form, so a one-call graph does not need a second node on the canvas.
The wired port wins: with a configuration node in the amocrm_config port this field is dimmed.
The priority is fixed: a wired port always beats the field. The port is the explicit, visible authority; the field is the shortcut. The form therefore dims the field and states the precedence instead of leaving two live sources on screen.
Workspace secrets
Not everything an external service needs is a connection. An arbitrary string — a
third-party API key for the HTTP request node, a webhook signature, a channel id — lives in
Settings → Secrets and is substituted
into any templated field as {{ secret.NAME }}. Secrets are decrypted once per run and are
available in every node of the graph — details and the other template namespaces are on
Templates and variables.
Who may change them
Any workspace member can see the connection list — but the list only: names, kinds and “secret is filled” markers, never values. Only a workspace admin may create, edit and delete them; everyone else sees a line saying admin rights are required. The same rule applies to secrets. Roles are covered on Team access.
Every creation, change and deletion of a connection is written to the workspace audit log.