Интеграции: обзор
Интеграция — это сохранённое подключение к внешнему сервису: адрес сервера, логин и секрет, лежащие в рабочем пространстве, а не в графе. Нода в сценарии на такое подключение только ссылается; ни токена, ни пароля внутри ноды нет.
Разделение сделано ради трёх вещей. Секреты хранятся зашифрованными в отдельной колонке и наружу не отдаются: список подключений показывает только, какие поля секретов заполнены, а не их значения. Один и тот же почтовый ящик или портал CRM переиспользуется десятком сценариев — сменить пароль надо в одном месте. И граф можно спокойно экспортировать, показать коллеге или отдать ассистенту: в нём лежит только идентификатор подключения.
Где они заводятся
Раздел Настройки → Интеграции. Слева список уже заведённых, справа форма выбранного. Кнопка Добавить интеграцию открывает выбор вида — вид выбирается один раз и после создания не меняется, потому что от него зависит и набор полей, и то, какие ноды увидят это подключение в своём выпадающем списке.
Настройки
Интеграции
Роутеры моделей, LLM-провайдеры и подключения к внешним сервисам.
| Название | Тип | Секреты |
|---|---|---|
| Почта поддержки | пароль сохранён | |
| amoCRM продажи | amoCRM | токен сохранён |
| Бот магазина | Telegram bot | токен сохранён |
| Календарь мастеров | CalDAV | пароль не задан |
Поле секрета при редактировании ведёт себя не как обычное: пустое значение означает «оставить текущее», а не «стереть». Так форму можно сохранить, не вводя пароль заново, и так же сервер ни разу не отдаёт секрет обратно в браузер.
Десять видов подключений
| Вид | Что в нём хранится | Кто им пользуется |
|---|---|---|
| хост IMAP/POP3 и SMTP, порты, логин, пароль | почтовые ноды | |
| WebDAV | базовый URL, логин, пароль, таймаут | внешнее файловое хранилище |
| CalDAV | базовый URL, логин, пароль, режим обнаружения календарей | ноды календаря |
| MCP | URL сервера, тип авторизации и токен, режим работы | нода mcp_tool |
| Свой ключ модели | адрес сервиса, ключ, список моделей и их назначение | ноды модели, эмбеддингов, реранка |
| Telegram bot | токен бота, имя бота | канал Telegram и его ноды |
| Цепочка резервных моделей | порядок моделей и условия перехода; своих секретов нет | нода модели |
| Bitrix24 | URL входящего вебхука, опционально домен портала | нода bitrix24_rest_call |
| amoCRM | поддомен аккаунта и долгоживущий токен | нода amocrm_rest_call |
| VK | токен доступа сообщества, версия API | канал ВКонтакте и его ноды |
Все они перечислены в выпадающем списке Тип диалога создания.
Проверка подключения есть не у всех
Кнопка Проверить подключение появляется ровно у трёх видов — Email, WebDAV и CalDAV. Это не недоделка, а осознанная граница: остальные подключения — HTTP-API, которые на первом же вызове отвечают внятной ошибкой провайдера («неверный токен», «нет прав»), и отдельная кнопка добавила бы поверхность, не добавив диагноза. А почта и DAV ломаются молча: до первого запуска сценария никто никуда не звонит, и опечатка в хосте SMTP или пароль вместо пароля приложения обнаруживаются днями позже упавшим раном.
Что стоит знать про саму проверку:
- она идёт по ногам, а не по подключению целиком: у почты это две независимые сессии (ящик и отправка) с разными хостами и портами, поэтому ответ бывает «IMAP работает, SMTP не пустил» — именно та диагностика, которой форма иначе не даёт;
- проверяется сохранённая версия, а не то, что вы сейчас набрали в форме;
- бюджет на проверку — двадцать секунд, после чего она возвращает «сервер не ответил». Так сделано намеренно: проверка держит соединение с базой на время запроса, и длинный таймаут на десятке зависших хостов выел бы пул соединений всего API;
- текст ошибки приходит от сервера дословно, но из него вырезаются значения секретов — болтливый почтовый сервер, эхом повторяющий строку логина, не должен превращать проверку в способ посмотреть пароль.
Как нода получает подключение
Способа два, и они сосуществуют.
Отдельная нода-конфигурация. На холст ставится нода вида <сервис>_config
(telegram_config, email_config, caldav_config, amocrm_config и так далее), в ней
выбирается сохранённое подключение, и её выход ведётся проводом данных в порт
<сервис>_config рабочей ноды. Приём тот же, что у модели: конфигурация — это отдельную
ноду, который подключается сбоку и на порядок исполнения не влияет. Провод, правда, другой:
у модели это link_llm, у интеграций — обычный data (см. Провода).
- Исполнение + данные
- Данные
Выбор прямо в ноде. У рабочих нод интеграций есть поле выбора подключения в собственной форме — чтобы граф из одного вызова не требовал второй ноды на холсте.
Подключённый порт выигрывает: если в порт amocrm_config заведена нода-конфигурация, поле гасится.
Приоритет фиксированный: подключённый порт всегда сильнее поля. Порт — явная и видимая на холсте связь, поле — сокращение; форма поэтому гасит поле и прямо пишет, кто выигрывает, вместо того чтобы держать на экране два живых источника.
Секреты рабочего пространства
Не всё, что нужно внешнему сервису, — это подключение. Произвольная строка (ключ стороннего
API для ноды HTTP-запроса, подпись вебхука, идентификатор канала) хранится в
Настройки → Секреты и подставляется
в любое шаблонное поле как {{ secret.ИМЯ }}. Секреты расшифровываются один раз на запуск и
доступны в любой ноде графа — подробности и остальные пространства имён шаблонов на странице
Шаблоны и переменные.
Кто имеет право менять
Список подключений видит любой участник рабочего пространства — но именно список: названия, виды и отметки «секрет заполнен», без значений. Создавать, редактировать и удалять их может только администратор пространства; у остальных форма показывает строку «для изменения интеграций требуются права администратора». То же правило у секретов. Разбор ролей — на странице Доступ команды.
Каждое создание, изменение и удаление подключения пишется в журнал аудита пространства.