Содержание
Как подключить GigaChat к n8n: пошаговый маршрут
Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.
Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 13 октября 2026 года; цитаты источников приведены дословно. Обновлено: октябрь 2026.
Подключить GigaChat к n8n удобнее всего через узел HTTP Request: для действующего проекта Studio вы получаете Authorization Key в кабинете GigaChat API, обмениваете его на access token по OAuth-схеме, а затем передаёте токен в заголовке Bearer при запросе к модели. Готовая community-нода существует, и о ней сказано ниже, но документированный маршрут от Сбера и n8n собирается на стандартных узлах. Скачали подборку результатов веб-поиска по запросу «Как подключить GigaChat к n8n»: текст отдали 9 из 10 страниц, медиана объёма читаемого текста топа — 1152 слова.
Мы скачали подборку результатов веб-поиска по запросу «Как подключить GigaChat к n8n»: текст отдали 9 из 10.
Прямой ответ и границы продукта
GigaChat — это API языковых моделей от Сбера, а n8n — конструктор автоматизаций, где вы соединяете узлы в workflow. Связка строится так: узел HTTP Request вызывает два адреса — OAuth-эндпоинт за токеном и endpoint чата за ответом модели. Здесь используем HTTP Request и примеры REST-запросов из документации Сбера.
Границы задачи очерчены: вы получаете два узла и соединяете их данными. Сбор заявок из Telegram, приём писем или обработка файлов — отдельные сюжеты, и здесь они не разбираются, потому что статья про подключение модели.
Ещё одна граница — учётная запись. GigaChat API живёт в личном кабинете Studio, и ключи выдаются там. Если вы работаете только в n8n, вам всё равно понадобится доступ к кабинету Сбера, чтобы создать проект и получить ключ. Перед настройкой убедитесь, что выбран именно API вашего действующего проекта.
Сравнить подходы можно с подключением DeepSeek к VSCode.
Условия доступа и источник актуальных требований
Этот порядок предназначен для действующих клиентов GigaChat API, которым доступен проект в Studio и прежний механизм покупки токенов. Документация Сбера указывает: с 1 сентября 2026 года новые клиенты и клиенты, ранее не покупавшие пакеты, оплачивают модели через cloud.ru. У cloud.ru нужно отдельно сверить ключи, адреса и условия своего API: описанный ниже OAuth-маршрут Studio нельзя автоматически переносить туда.
Источник актуальных требований — документация разработчиков Сбера. Там же описан порядок выдачи ключа. В первичной инструкции сказано: откройте проект GigaChat API в личном кабинете Studio, в левой панели выберите раздел «Настройки API», нажмите кнопку «Получить ключ», после чего откроется окно «Сохраните ваш Authorization Key».
Этот ключ — базовое значение для входа. По документации Сбера access token нужен для авторизации запросов к GigaChat API по Bearer-схеме. Один ключ даёт вам возможность получать токены, а токен уже подтверждает каждый конкретный запрос к модели.
Второй источник требований — документация n8n. Она определяет, какие поля узла HTTP Request заполнять, как передавать тело запроса и заголовки. Из неё же берётся приём переноса curl-примеров: если документация сервиса даёт примеры curl, их можно скопировать в n8n для настройки узла HTTP Request.
Документированный порядок действий
Сборка идёт из двух узлов. Первый узел получает токен. По первичной документации Сбера запрос к OAuth выглядит так: POST на адрес https://ngw.devices.sberbank.ru:9443/api/v2/oauth, заголовки Content-Type application/x-www-form-urlencoded, Accept application/json, RqUID с уникальным идентификатором запроса и Authorization Basic с вашим Authorization Key, а в теле scope=GIGACHAT_API_PERS.
На выходе первого узла приходит access token. Дальше второй узел вызывает модель. По документации Сбера это POST на https://api.giga.chat/v1/chat/completions с заголовками Content-Type application/json, Accept application/json и Authorization Bearer с токеном доступа, а тело — JSON с массивом сообщений и указанием модели.
В n8n для второго узла выбираете передачу тела как JSON. Документация n8n описывает эту опцию: при выборе JSON вы вводите JSON для определения тела. Поле с токеном подставляете из первого узла, чтобы не переносить значение вручную.
Порядок действий коротко:
- В кабинете Studio открываете проект GigaChat API и получаете Authorization Key.
- В n8n добавляете узел HTTP Request, настраиваете POST на OAuth-адрес с urlencoded-телом и scope.
- Заголовок Authorization заполняете по Basic-схеме с ключом, RqUID — уникальным значением запроса.
- Из ответа первого узла забираете access token.
- Вторым узлом HTTP Request делаете POST к endpoint чата с Bearer и JSON-телом.
- Проверяете ответ и место, где лежит текст сообщения модели.
Проверка самостоятельная: на первом шаге в ответе должен появиться токен, на втором — объект ответа модели. Если токен пустой, смотрите заголовки и тело OAuth-запроса.
Оригинальный учебный пример и критерии проверки
Возьмите рабочую задачу попроще: пусть workflow принимает короткий текст обращения и получает от модели ответ. Учебный пример строится на двух узлах и ручном запуске — больше в базовом маршруте ничего не требуется.
Промпт, чтобы получить от GigaChat разбор текста обращения:
Ты помощник, который разбирает обращения клиентов.
Прочитай текст: [текст обращения]
Верни ответ в формате:
Тема: [о чём обращение]
Тон: [спокойный/раздражённый/нейтральный]
Вопрос: [что человек хочет узнать]
Черновик ответа: [короткий ответ по делу]
В квадратных скобках подставьте своё: [текст обращения] — реальный текст для проверки, формулировки полей — свои. Числовые ограничения длины добавьте сами, если они нужны в вашем процессе.
Критерии проверки, которые видит сам автор workflow:
- Токен получен, ответ OAuth содержит поле с токеном.
- Запрос к модели уходит с заголовком Authorization в Bearer-варианте.
- Тело запроса уходит как JSON и содержит массив сообщений с ролью пользователя.
- Ответ модели разобран, текст сообщения извлечён в отдельное поле.
- Повторный запуск через полчаса подтверждает, что токен обновляется и запрос проходит.
Вариации той же задачи, если базовая проверка прошла:
- Классификация обращения по теме с фиксированным списком тем.
- Извлечение данных из текста в структуру, например города и даты.
- Переформулировка текста в вежливый ответ клиенту.
- Сводка длинного текста в несколько пунктов.
- Проверка тона и подсказка, когда обращение стоит эскалировать.
Каждая вариация использует тот же узел запроса, меняется только формулировка сообщения. Развёрнутые примеры запросов к GigaChat есть в материале о работе в Гигачате; принципы постановки задачи там переносятся и на API.
Смежные варианты и что выбирать по задаче
Вариантов подключения два: ручной маршрут на HTTP Request и community-нода для n8n. Ручной маршрут использует только стандартные узлы, и вся логика видна вам целиком. Community-нода избавляет от ручной сборки, но это сторонний проект.
По первичным страницам видно, что community-решения существуют и описаны на GitHub и в каталоге npm. Пакет n8n-nodes-gigachat на GitHub описывает узлы GigaChat для n8n, включая работу с чатом и эмбеддингами. В каталоге NCNodes тот же пакет значится как community-пакет для n8n.
Выбор идёт по задаче. Когда нужен один запрос к модели и полный контроль над параметрами — ручной маршрут на HTTP Request даёт прозрачную схему. Когда таких мест в workflow много и вы часто меняете параметры — community-нода экономит сборку.
Сравнение по ключевым признакам:
| Признак | HTTP Request | Community-нода |
|---|---|---|
| Источник узлов | Ядро n8n | Сторонний пакет |
| Получение токена | Отдельный узел OAuth | Проверяется по документации пакета |
| Контроль параметров | Полный | Задан авторами пакета |
| Обновление логики | Ваша правка | Обновление пакета |
| Работа с эмбеддингами | Собирается вручную | Описана в пакете |
| Подходит для | Прозрачного маршрута | Повторяемых сценариев |
Второй смежный вопрос — какую модель вызывать. Поле модели стоит в теле запроса, и его значение вы берёте из документации Сбера на момент настройки. Здесь важно не склеивать разные линейки моделей: имя, которое подходит чату, может отличаться от имени модели для эмбеддингов.
Третий смежный выбор — где хранить ключ. Authorization Key долгоживущий, токен живёт 30 минут. Ключ размещайте в credentials, токен получайте в ходе выполнения. Первичная документация Сбера описывает выдачу ключа в кабинете, и это единственное документированное место его появления.
Типичные проблемы и проверяемые способы диагностики
Сначала проверьте сертификаты: документация Сбера требует установить сертификаты НУЦ Минцифры. В среде, где выполняется n8n, настройте доверенное хранилище сертификатов; для контейнера это отдельная конфигурация его окружения. Сохраняйте проверку TLS при запросах.
Первая проблема — истечение токена. По документации Сбера он действителен 30 минут, поэтому сценарий с сохранённым значением перестаёт работать по расписанию. Проверка: запустите workflow, перезапустите через полчаса и посмотрите, на каком шаге падает ответ. Решение — получать токен перед каждым обращением или обновлять его по расписанию.
Вторая проблема — схемы авторизации перепутаны. OAuth принимает Basic с Authorization Key, а сам чат ждёт Bearer с токеном. Проверка: сверьте заголовок каждого узла с примерами первичной документации Сбера и не переносите ключ туда, где нужен токен.
Третья проблема — перепутанные credentials. Ключи GigaChat, OpenAI и DeepSeek живут в разных наборах, и подстановка «чужого» ключа даёт отказ авторизации. Проверка: откройте настройки credentials и убедитесь, что в узле выбран набор, созданный именно под GigaChat.
Пятая проблема — переменные окружения в n8n 1.x. В том же обзоре на Хабре отмечена особенность с переменными $env в n8n 1.x. Проверка: убедитесь, что значение переменной видно внутри выражения узла, и сравните поведение на своей версии.
Шестая проблема — тело запроса. Документация n8n разводит два режима: тело как urlencoded и тело как JSON. OAuth требует первый, чат — второй. Проверка: посмотрите на выбранный режим и на сигнатуру примера из документации Сбера.
Частые вопросы
Как подключить n8n gigachat без сторонних пакетов?
Маршрут на стандартных узлах начинается с получения Authorization Key в кабинете Studio и обмена его на access token через OAuth. Токен передаётся в заголовке Bearer при запросе к модели вторым узлом HTTP Request. Документация n8n описывает HTTP Request как инструмент для сервисов, не поддержанных платформой напрямую, и даёт вариант тела urlencoded. Этого набора достаточно для минимального workflow.
Сколько живёт токен GigaChat и что делать после истечения?
По документации Сбера токен доступа действителен 30 минут. В ручном сценарии вы перезапрашиваете его перед новым обращением. В автоматическом — ставите получение токена отдельным шагом или обновляете его по расписанию. Проверка простая: запустите workflow дважды с паузой и посмотрите, на каком шаге появляется отказ.
Чем отличаются credentials n8n для GigaChat и OpenAI?
Это разные наборы учётных данных с разными ключами и схемами авторизации. GigaChat использует Authorization Key из кабинета Studio и Bearer-токен, полученный по OAuth. Если в узле выбран набор от другой модели, запрос не пройдёт авторизацию. Проверяйте выбранный набор в настройках каждого узла.
Почему при запросе к GigaChat в Docker возникает ошибка сертификата?
В обзорах на Хабре описан симптом UNABLE_TO_VERIFY_LEAF_SIGNATURE и разбор корневого сертификата Минцифры внутри Docker. Там же сказано, что отключать TLS не стоит, а сертификат нужно настраивать штатно. Сверьте конфигурацию контейнера с описанным случаем и загрузите сертификат в доверенное хранилище.
Как проверить, что ответ модели приходит корректно?
Смотрите на объект ответа второго узла: в нём должен быть массив с сообщением модели и отдельное поле с текстом. Извлеките текст в самостоятельное поле и выведите его для проверки. Если текст пустой, сверьте тело запроса с примером из документации Сбера, начиная с массива сообщений и роли пользователя.