Подключить LLM API к n8n можно через стандартный узел HTTP Request: отправьте POST-запрос на https://api.llmtokenapi.ru/v1/responses, передайте API-ключ в заголовке Authorization и сформируйте JSON с моделью и входным текстом. Отдельный нативный узел не нужен — workflow работает с обычным REST API и может тем же ключом обращаться к поиску и web-данным.
Как выглядит минимальный workflow
Для первой проверки достаточно трёх узлов: Manual Trigger, Set и HTTP Request. В Set положите тестовое поле text, например короткое обращение клиента. HTTP Request передаст его модели, а следующий узел сохранит или отправит полученный ответ.
Такую схему удобно проверять до подключения Telegram, CRM или webhook. Если запрос проходит вручную, источник события можно заменить без изменения контракта с моделью. Это отделяет проблемы авторизации и тела запроса от ошибок конкретного канала.
Официальная документация HTTP Request в n8n подтверждает, что узел умеет отправлять POST-запросы, заголовки и JSON-тело. Актуальные endpoint, scopes и примеры LLMTOKENAPI опубликованы в документации API.
Создайте ключ с нужным scope
Для Responses API ключу нужен scope llm:read. Храните секрет в credentials n8n или в защищённой переменной окружения инстанса. Не вставляйте рабочий ключ в название узла, заметки workflow, тестовые данные или сообщения об ошибках: экспортированный workflow могут передать коллеге или сохранить в Git.
Если сценарий позже будет обращаться к интернет-поиску, добавьте ключу search:read. Для чтения страниц потребуется web:read. Принцип минимальных прав полезен даже в небольшом проекте: утечка ключа не должна автоматически открывать все операции аккаунта.
Настройте HTTP Request
В узле укажите следующие параметры:
- Method —
POST. - URL —
https://api.llmtokenapi.ru/v1/responses. - Authentication — Header Auth либо передача заголовка через защищённые credentials.
- Заголовок
Authorization—Bearer <API_KEY>. - Body Content Type — JSON.
- Response Format — JSON.
Тело первого запроса может быть таким:
{
"model": "gpt-5.4-mini",
"input": "Сделай краткое резюме: {{$json.text}}"
}
ID в примере доступен на момент публикации, но каталог меняется. Для долгоживущей автоматизации выбирайте модель из GET /v1/models и храните её ID в одной переменной workflow, чтобы не редактировать десятки узлов при замене.
Передавайте данные из предыдущего узла
n8n обрабатывает элементы последовательно, поэтому в JSON можно использовать expression из входного item. Не подставляйте весь объект без необходимости: выберите конкретные поля, ограничьте длину пользовательского текста и отдельно сформулируйте инструкцию модели.
Для входящих webhook полезно сначала поставить Set или Code: нормализовать поле, удалить пустые значения и проверить обязательные данные. Тогда HTTP Request получает предсказуемый JSON, а ошибка входного формата не маскируется под проблему LLM API.
Ответ Responses API — объект, а готовый текст находится в его выходных элементах. Если дальнейший узел ожидает простую строку, добавьте Set и выделите нужное значение после тестового выполнения. Не привязывайте бизнес-логику ко всему ответу целиком: служебные поля могут быть полезны для диагностики, но обычно не нужны в сообщении пользователю.
Добавьте интернет-поиск вторым узлом
Если автоматизация должна отвечать по свежим данным, сначала вызовите POST /v1/search, затем передайте модели только релевантные результаты. Один API-ключ и общий базовый адрес позволяют собрать цепочку «событие → поиск → ответ» без отдельной учётной записи поискового сервиса.
Поиск и генерация — разные операции и scopes, поэтому их лучше оставить отдельными узлами. Так видны задержка, статус и результат каждого шага. Для ответа, который сразу включает проверяемые источники, рассмотрите архитектуру AI-поиска с цитатами.
Обрабатывайте ошибки явно
По умолчанию HTTP Request считает успешными ответы 2xx. Не включайте Never Error без причины: иначе workflow может принять JSON ошибки за ответ модели. Разведите минимум четыре ситуации — неверный ключ, недостаточный scope, недостаточный баланс и временная ошибка модели или лимита.
Для временных 429, 502 и 503 допустим ограниченный повтор с увеличивающейся задержкой. Для 401, 402 и 403 автоматический повтор обычно бессмысленен: нужны новый ключ, права или пополнение. Сохраняйте requestId из ошибки, но не тело пользовательского запроса и не секрет.
Также задайте timeout на стороне n8n. Он должен быть больше нормального времени ответа, но конечным, чтобы зависший запуск не держал очередь бесконечно. Если узел уже получил успешный ответ, следующий шаг делайте идемпотентным: повторное выполнение не должно дважды отправить письмо или создать две записи в CRM.
Проверьте workflow перед активацией
Запустите сценарий вручную с коротким безопасным текстом и проверьте статус, модель и извлечённый результат. Затем протестируйте пустой вход, слишком длинное сообщение, намеренно неверный ключ и временный повтор. После этого замените Manual Trigger реальным событием и активируйте workflow.
Рабочий критерий готовности прост: один внешний запуск n8n формирует валидный запрос, получает ответ, корректно обрабатывает ошибку и не раскрывает ключ в execution data. Готовую конфигурацию для n8n также можно скопировать после создания ключа в кабинете LLMTOKENAPI.
