@BotFather: как создать собственного бота в Telegram

@BotFather — это официальный бот Telegram, через которого создаются все остальные боты. Других способов завести бот нет: ни сайта, ни приложения, ни консоли — только переписка с этим аккаунтом.

Зачем это нужно

Чтобы любой workflow (в n8n, Make, на собственном бэкенде) мог слушать сообщения и отвечать от имени бота, ему нужен токен Bot API. Токен выдаётся при создании бота через @BotFather. Без токена ни одна интеграция с Telegram не заведётся: токен — это пара «логин-пароль» бота при общении с Telegram Bot API.

Как это работает

Открываешь Telegram, в поиске находишь аккаунт с username BotFather (галка подлинности рядом с именем — синяя), и пишешь ему как обычному собеседнику. Команды начинаются со слэша:

• /newbot — создать нового бота. @BotFather спросит две вещи:
• отображаемое имя (любое, может быть с пробелами и кириллицей) — то, что увидят пользователи в шапке чата;
• username (только латиница, цифры, подчёркивание; обязательно заканчивается на _bot или bot) — постоянный идентификатор, по которому бот ищется и не меняется.
• /mybots — список всех твоих ботов, доступ к настройкам (имя, описание, аватарка, команды, токен).
• /revoke — отозвать старый токен и получить новый (если старый утёк).

После /newbot приходит сообщение с токеном — длинная строка вида 123456789:ABCdefGHI_jklMNO.... Это и есть тот самый Bot API token: его копируешь и сохраняешь в безопасное место (менеджер паролей, заметки с шифрованием) — но не в публичный репозиторий и не в чат.

Типичные ошибки

• Потерять токен — @BotFather показывает токен один раз; чтобы получить его снова, нужно открыть /mybots → <твой бот> → API Token. Если не нашёл — можно сгенерировать новый через /revoke, но тогда старый перестанет работать во всех уже настроенных интеграциях.
• Скинуть токен скриншотом / в открытый чат — токен даёт полный контроль над ботом. Любой, кто его увидит, может слать сообщения от имени бота и читать всё, что ему приходит. Если утёк — сразу /revoke.
• Username без _bot на конце — @BotFather отклонит регистрацию; правило жёсткое, придётся подбирать ещё.
• Перепутали username и отображаемое имя — отображаемое имя меняется в любой момент через /setname, а username меняется только пересозданием бота. Если задумывался серьёзный бот — username стоит выбрать осознанно.

Когда не подходит

Через @BotFather нельзя создать юзербот (бот, который ходит под обычным аккаунтом) — это уже не Bot API, а MTProto, и токен оттуда не подходит. Также @BotFather не нужен, если бот уже создан кем-то другим и тебе просто передали готовый токен — тогда сразу заводишь credential в нужном сервисе и работаешь с ним.

RSS — лента, которую забирают по расписанию

RSS — это адрес вида https://site.ru/feed.xml, по которому сайт отдаёт список последних записей в машинно-читаемом виде. Любая программа может скачать этот файл и получить заголовки, ссылки и даты публикаций без посещения страниц.

Это pull-модель. Сайт не отправляет уведомления сам. Подписчик сам обращается к ленте через равные промежутки времени и сравнивает, что появилось нового.

Каждая запись в ленте содержит стандартный набор полей: заголовок, ссылка, дата публикации и обычно короткий текст или фрагмент. Запись считается новой, если её не было в предыдущей выдаче. Именно это сравнение и даёт триггер для автоматизации.

RSS встречается на блогах, новостных сайтах, в релизах GitHub, подкастах и на форумах. Специальные ноды RSS Read и RSS Feed Trigger сами разбирают XML и отдают готовый массив items. Парсить руками не нужно.

Как это работает

Сайт публикует файл ленты и обновляет его при появлении новых материалов. Клиент (в том числе n8n) периодически скачивает этот файл целиком. Сравнивает список записей с тем, что было в прошлый раз, и обрабатывает только новые элементы.

• Лента обновляется не мгновенно. Между публикацией и появлением записи в XML может пройти от нескольких минут до часа.
• Поля title, link, pubDate и content уже разобраны нодами, их можно сразу использовать в выражениях.
• Если ленты на сайте нет, RSS не поможет. Нужно искать API или парсить страницы напрямую.

Типичные ошибки

• Ждут push-уведомлений от сайта → лента не меняется до следующего опроса → нужно настроить расписание и закладывать задержку в сценарий.
• Пытаются получить запись через секунды после публикации → лента обновляется с лагом → проверять наличие записи не раньше чем через 15–30 минут.
• Используют RSS для сбора данных с любого сайта → у многих ресурсов ленты просто нет → искать официальный API или переходить к парсингу HTML.
• Пробуют разбирать XML регулярными выражениями → ноды уже возвращают готовый массив с полями title, link и pubDate → работать с этими полями напрямую, не лезть в исходный XML.

Polling-триггер: как нода сама ходит за данными

Polling-триггер — это нода, которая периодически сама обращается к источнику данных по расписанию. Она не ждёт уведомления извне, а каждые N секунд или минут отправляет запрос и проверяет, появились ли новые записи.

Такой механизм называют pull-моделью: инициатива всегда у n8n. Источник (RSS, база данных, старый API) ничего не знает о клиенте и не умеет сам отправлять данные.

Как это работает

Polling-триггер работает в два этапа. При первом запуске нода получает все доступные записи и сохраняет слепок состояния — «что уже видело». При последующих запусках она запрашивает данные заново и отдаёт только те записи, которых не было в слепке.

Слепок сохраняется только после того, как workflow переведён в режим Published. В режиме Test слепок не фиксируется, поэтому каждый тест возвращает одни и те же данные.

Сравнение с push-моделью (Webhook):

Polling применяют, когда у источника нет Webhook: RSS-ленты, старые SaaS, прямой доступ к базе или файлам на диске. Пример — RSS Feed Trigger.

Типичные ошибки

• Выбрал интервал 5 секунд → быстро исчерпал квоту API источника и получил rate-limit → поставь интервал, который соответствует реальной скорости появления данных.
• Поставил интервал 1 час → новые записи приходят с задержкой до часа → уменьши интервал, если данные критичны по времени.
• Ожидал, что RSS Feed Trigger поведёт себя как Webhook → workflow не запустился при обновлении ленты → помни, что polling сам инициирует запросы, а webhook ждёт входящий вызов.
• Проверил триггер в режиме Test → каждый тест возвращает одни и те же записи → перейди в Published, чтобы слепок состояния начал сохраняться.

Добавление ноды на canvas

Чтобы продолжить цепочку, нужно вставить новую ноду после существующей или на пустой canvas. Для этого открывают панель выбора нод тремя способами: кнопка Open nodes panel в центре canvas, кнопка Add node на стрелке соединения и + на output-коннекторе любой ноды.

Панель называется What happens next?. В ней сразу видно категории и поле поиска.

Как это работает

• Клик по Open nodes panel или Add node открывает список.
• В поле Search nodes... вводят имя ноды или сервиса (например http, slack, schedule). Список фильтруется по мере ввода.
• Навигация по категориям: AI, Action in an app, Data transformation, Flow, Core, Human review, Add another trigger.
• Клик по названию ноды ставит её на canvas и сразу открывает панель Parameters.
• На пустом canvas можно нажать клавишу Tab — откроется та же панель без клика мышью.

Первая нода любого воркфлоу должна быть триггером (Schedule Trigger, Webhook, Manual и подобные). Обычные ноды-действия в начало ставить нельзя.

Типичные ошибки

• Поставил обычную ноду первой → воркфлоу не из чего стартовать → замени первую ноду на триггер из категории Core или через поиск.
• Ищут ноду по русскому названию → список остаётся пустым → вводи английское имя сервиса в поле Search nodes....
• Целятся мышью в мелкий + на стрелке → промахиваются → нажми Tab прямо на canvas.
• Открывают категорию Add another trigger после уже существующей ноды → добавляют лишний триггер → для обычного шага используй поиск или категории Action in an app и Data transformation.

Запустить одну ноду, не дёргая весь workflow

Execute step — это кнопка внутри панели ноды (открывается двойным кликом по ноде). По смыслу — младший брат большой кнопки Execute workflow внизу холста: та запускает весь воркфлоу с начала, эта — только текущую ноду. Удобно, когда настраиваешь параметры и хочешь сразу видеть, что отдаёт нода, не перезапуская всю цепочку.

Как это работает

Когда ты жмёшь Execute step, n8n берёт уже существующие данные на входе ноды (output предыдущей ноды из последнего прогона) и прогоняет через эту ноду. Сама нода выполняется реально: HTTP-запрос уходит, запись в базу пишется, письмо отправляется. Это не «сухой прогон», а полноценное выполнение — только одного шага.

Типичный сценарий: запустил весь воркфлоу один раз (Execute workflow), увидел что нода HTTP Request отдаёт не то, поправил поле URL, нажал Execute step — увидел новый результат за секунду. Предыдущие ноды повторно не выполнялись.

Типичные ошибки

• Жать Execute step на ноде, у которой ещё не было входных данных → «No input data», нода не запустится. Сначала прогони весь воркфлоу через Execute workflow или хотя бы триггер вручную, чтобы у каждой ноды появился output.
• Использовать Execute step для проверки изменений в предыдущих нодах → текущая нода работает со старым output, изменения не подхватятся. Если поправил предыдущую ноду — перезапусти её, а потом уже текущую.
• Тестировать ноду с побочным эффектом (запись в БД, отправка письма) на проде → каждый клик создаёт реальную запись. Использовать тестовый credential или временно подменять параметры на безопасные.

Pin Data в n8n: как зафиксировать тестовый вход ноды

Pin Data — это способ «прибить» к ноде заранее заготовленные данные, которые n8n будет подставлять вместо настоящего входа на каждом тестовом запуске. Полезно, когда дёргать реальный источник (внешний воркфлоу, веб-хук, API) на каждое нажатие Execute workflow неудобно или невозможно.

Зачем это нужно

Часто отлаживается не сам триггер, а ноды после него — логика, маппинг, запрос в базу. Чтобы не звать каждый раз источник данных (другой воркфлоу, бот, форму), удобнее один раз получить пример настоящего входа, зафиксировать его на триггере и потом крутить запуски сколько нужно.

Поэтому Pin Data — это инструмент разработчика на этапе сборки, не часть рабочего воркфлоу. В боевом режиме закреплённые данные перестают использоваться: n8n берёт реальный вход.

Как это работает

К любой ноде с выходом можно прикрепить «запинённый» JSON. После этого:

• При запуске воркфлоу через UI (Execute workflow, тестовый прогон) n8n не вызывает саму ноду, а сразу выдаёт следующим нодам зафиксированные данные.
• Pin Data привязана к конкретной ноде, не к workflow целиком — можно запинить триггер и оставить остальные ноды живыми.
• На холсте у запинённой ноды появляется визуальный значок (булавка/иконка), чтобы не забыть, что данные «искусственные».

Удобнее всего пинить триггер: на нём поле выхода — то, что в боевом режиме приходит снаружи (Telegram-апдейт, тело веб-хука, поля Execute Workflow Trigger). Тестовый JSON собирают с теми же ключами, что отдаёт реальный источник.

Типичные ошибки

• Забыли про пин при отладке — в редакторе тестовые прогоны идут по закреплённым данным, а не по реальным, поэтому новый вход «не доходит». Боевому запуску пин не мешает, но перед проверкой на живых данных его лучше снять.
• Структура запинённого JSON не совпадает с реальным — отладка проходит идеально, но в проде ломается на полях, которых не было в тестовом примере; делайте пин из реальной execution, а не «на глаз».
• Запинили середину воркфлоу, забыли — переименовали поле в ноде до пина, а пин остался со старой структурой. Следующие ноды читают «фантомные» данные.
• Pin Data перепутали с переменными среды — пин не передаётся между воркфлоу и не сохраняется при экспорте на другую инсталляцию n8n как «конфиг»; это именно отладочный фиксаж.

Когда не подходит

Pin Data не заменяет настоящие тесты — это удобство в редакторе, не автоматизация. Если нужна повторяемая проверка с разными входами, лучше делать отдельный тестовый workflow или мини-набор тест-кейсов; пин подходит, когда хочется быстро прогнать «один и тот же» сценарий N раз.

Три ноды — одна модель, три разных задачи

В n8n запрос к языковой модели можно отправить тремя классами нод: нативная нода вендора (OpenAI, Anthropic, Google Gemini — пункт «Message a Model»), Basic LLM Chain и AI Agent. У всех трёх под капотом — вызов LLM, но устроены они по-разному и решают разные задачи. Выбор не на вкус: для одного кейса подходит одна, для другого — другая.

Когда что выбирать

• Нативная нода вендора — когда нужен один простой вызов к конкретной модели и больше ничего: классификатор текста, переписать одно сообщение, извлечь сущности по промпту. Минимум абстракций, максимум контроля над параметрами вендорского API (например, response_format у OpenAI). Память истории придётся собирать руками — нода её не ведёт.
• Basic LLM Chain — когда нужен один вызов, но с возможностью менять модели и/или вытаскивать структурированный вывод через парсер. Типичный кейс: «сгенерируй JSON по схеме». Сегодня модель OpenAI, завтра — Gemini, ноду переключать не надо, меняешь только sub-ноду Chat Model.
• AI Agent — когда модели нужны инструменты (поиск в БД, вызов API, доступ к Sub-Workflow) или память диалога между сообщениями пользователя. Бот, который помнит разговор, ассистент с инструментами, агент с RAG — это AI Agent. Бот, который отвечает на каждый вопрос отдельно, без памяти и инструментов, обходится Basic LLM Chain.

Типичные ошибки

• Поставил AI Agent, потому что «звучит модно», без инструментов и памяти → переплачиваешь токенами на служебный ReAct-промпт, получаешь то же, что дал бы Basic LLM Chain. Без tools — Chain.
• Взял нативную ноду OpenAI ради «структурированного JSON» → парсера у нативной ноды нет, ответ парсишь сам в следующей Code-ноде. Если нужен валидированный JSON по схеме — Basic LLM Chain с Output Parser sub-нодой.
• Подключил Chat Memory к Basic LLM Chain и ждёшь, что бот «запомнит» предыдущее сообщение → Basic LLM Chain не ведёт диалог, он делает один запрос за вызов. Для памяти диалога нужен AI Agent.
• Сменил вендора в нативной ноде → надо переписывать всю ноду заново (поля разные у OpenAI и Anthropic). В Basic LLM Chain / AI Agent — меняется только sub-нода Chat Model, остальное остаётся.

Source for Prompt — откуда Basic LLM Chain берёт текст для модели

У ноды Basic LLM Chain есть параметр Source for Prompt (User Message). Он управляет тем, откуда нода берёт пользовательский текст для передачи в языковую модель. Такой же параметр с теми же двумя режимами есть у AI Agent.

Connected Chat Trigger Node (дефолт) — нода ожидает что в воркфлоу есть Chat Trigger. Текст сообщения из чата автоматически передаётся в модель как prompt пользователя.

Точнее, в этом режиме нода берёт текст из поля chatInput входящего элемента. Пока между Chat Trigger и нодой ничего не стоит, поле на месте. Если перед нодой стоит нода, которая заменяет элемент и выбрасывает chatInput, — например Guardrails, — запуск падает с ошибкой No prompt specified, хотя Chat Trigger в воркфлоу есть.

Define below — нода не ждёт Chat Trigger. Ты сам формируешь prompt в поле Prompt (User Message): пишешь статичный текст инструкции и/или вставляешь данные из предыдущих нод через drag-and-drop.

Когда использовать Define below:

• Триггер — не чат (RSS, Schedule, Webhook, Form)
• Нужно добавить в prompt данные из других нод (текст статьи, содержимое формы, результат HTTP-запроса)
• Между чатом и нодой стоит нода, которая убирает поле chatInput: после Guardrails текст берут из её поля guardrailsInput — {{ $json.guardrailsInput }}

Типичный вид поля Prompt (User Message) в режиме Define below:

Сделай краткое саммари этой статьи в 3 предложениях: {{ $json.contentSnippet }}

Здесь первая часть — статичная инструкция, вторая — выражение с данными из RSS Feed Trigger.

Что такое expression

В n8n expression — это маленький кусочек кода в фигурных скобках, который динамически подставляет значение в поле ноды. Записывается так:

{{ <выражение> }}

В поле интерфейса = перед выражением писать не нужно: поле в режиме Expression уже трактует содержимое как выражение, а знак = n8n сам добавляет в файле воркфлоу (JSON) как маркер. Если напечатать = самому, он попадёт в результат текстом (например, сообщение начнётся с «=🚨»). Если поле осталось в режиме Fixed, {{ ... }} запишется как обычный текст.

Внутри {{ }} пишется JavaScript-выражение. Самое частое — чтение значения из другой ноды.

Зачем нужны expressions

Каждое поле в параметрах ноды может быть либо фиксированным значением (например, URL https://api.example.com), либо expression'ом — формулой, которая считается на лету в момент исполнения ноды. Expressions нужны, когда значение зависит от данных, пришедших из предыдущей ноды.

Как читать значения из других нод

Базовая формула: {{ $('<имя_ноды>').item.json.<поле> }}

Разбор по частям:

• $('<имя_ноды>') — обращение к ноде по имени (то, что написано на холсте под нодой). Имя — в одинарных кавычках, точно как на холсте.
• .item — текущий элемент, который обрабатывается. У большинства нод элементов несколько (массив), item берёт тот, что соответствует текущей итерации.
• .json — содержимое поля json элемента (там лежат все данные, которые нода вернула).
• .<поле> — конкретное поле внутри json. Если поле вложенное — пишется через точку: .config.embedding_model.

Пошагово — как вставить expression в поле

1. Наведи курсор на поле и переключи Fixed → Expression в правом верхнем углу поля (или просто начни вводить {{ — поле само перейдёт в режим expression).
2. В появившемся окне (expression builder) — слева список нод воркфлоу, можно кликать по полям и они вставятся в формулу.
3. Справа — preview: видно, какое значение получится прямо сейчас. Если красным — формула или путь к полю некорректные.
4. Закрой окно, поле остаётся в режиме expression (синий фон + иконка fx).

Типичные ошибки

• Имя ноды не совпадает. В формуле $('Get Config') имя должно точно совпадать с подписью ноды на холсте. Если переименовал ноду — старые expressions, ссылающиеся на неё, сломаются.
• Путь к полю не существует. .item.json.embedding_dimensions упадёт с undefined, если у элемента такого поля нет. Проверка — посмотри preview в expression builder, он сразу показывает значение или ошибку.
• Поле осталось в режиме Fixed. Самая частая ошибка — описана в callout выше.
• Кавычки внутри {{ }}. Внутри expression строки оборачиваются одинарными кавычками: {{ 'Hello ' + $json.name }}; двойные тоже работают. Поля с кириллицей и пробелами читаются как $json["Имя"].

Когда expression не нужен

Иногда поле должно быть фиксированным. Например, метод HTTP-запроса (GET / POST) или имя коллекции, которое одинаково для всего воркфлоу — нет смысла читать его динамически. Простое правило: если значение меняется от итерации к итерации или зависит от пришедших данных — нужен expression; если значение постоянное — оставляй фиксированным.

Перетаскивание полей из Input panel

Когда нужно подставить значение из предыдущей ноды в параметр текущей, не пиши выражение вручную. Открой ноду двойным кликом. Слева откроется Input panel с деревом полей предыдущей ноды. Справа — node parameters.

Раскрой нужное поле в Input panel и перетащи его мышкой в parameter's field. n8n сам сформирует выражение и переключит поле из режима Fixed в Expression.

Как это работает

Input panel показывает данные из OUTPUT предыдущей ноды. Данные приходят в виде дерева: каждое поле можно раскрыть до примитива.

После drop в parameter's field появляется выражение в двойных фигурных скобках. n8n поддерживает два формата:

• $json.<field> — когда данные идут напрямую из предыдущей ноды по главной ветке;
• $('<NodeName>').item.json.<field> — когда нужно явно указать имя ноды-источника.

n8n сам определяет нужный item через item linking. Ручной поиск соответствия не требуется.

Поле автоматически окрашивается и переключается в режим Expression. Альтернатива — открыть expressions editor и написать то же выражение вручную. Результат идентичен.

Вложенные поля раскрываются через точку: $json.body.city.

Типичные ошибки

• Перетащил объект-обёртку вместо примитива → в поле уходит [object Object] → раскрой дерево до листа.
• Дропнул в соседнее поле параметра (Text вместо Chat ID) → нода работает не на тех данных → визуально проверь куда легло выражение.
• Переименовал ноду уже после drag-and-drop → expression $('старое имя') сломался → верни старое имя или перепиши выражение вручную.
• Впечатал статичное значение через drag вместо обычного текста → лишнее выражение там где значение не меняется → для констант просто впечатывай текст.
• Тащишь из ноды через ветку которая не выполнялась → expression вернёт undefined → проверь что нужная ветка реально дошла до текущей ноды.

Что такое sub-нода

В n8n AI-ноды устроены как «родитель + дети». Родитель — основная нода (AI Agent, Qdrant Insert, Qdrant Vector Store…). Дети — sub-ноды, которые подключаются к специальным кружкам на нижней стороне родителя. Каждая sub-нода — это «поставщик ресурса» для родителя.

Какие бывают sub-ноды

• Embeddings — поставляет векторы (OpenAI / Cohere / Voyage / Google Gemini / bge / …).
• Chat Model — поставляет LLM для AI Agent, Basic LLM Chain и других AI-нод, например Guardrails.
• Document Loader — поставляет «нарезанные» куски документа.
• Text Splitter — внутри Document Loader, разбивает на чанки.
• Memory — поставляет историю диалога для AI Agent.
• Tool — поставляет инструменты, которые AI Agent может вызвать.

Когда родитель запускается (например, Qdrant Insert получил файл и собирается записать его в БД), он по очереди обращается к sub-нодам: «дай мне чанки», «переведи каждый чанк в вектор». Sub-ноды отвечают, родитель собирает результат.

Как выглядит sub-нода в параметрах родителя

Если открыть параметры родителя двойным кликом — справа выезжает панель параметров, а на нижней границе панели видны кружки sub-нод. Подключённая sub-нода показана как круглый цветной индикатор с иконкой провайдера. При наведении — всплывающая подсказка с именем и статусом.

Как заменить sub-ноду

1. Закрой панель параметров родителя (Esc).
2. На canvas найди подключённую sub-ноду — она расположена под родителем. Кликни на ней, нажми Delete (или правый клик → Delete). Sub-нода удалится, у родителя освободится слот.
3. На родителе освободившийся слот покажет «+» (например, Add document embedding). Нажми — справа откроется список доступных sub-нод нужного типа.

1. Выбери нужную sub-ноду — она автоматически подключится к родителю на освободившемся слоте.
2. Заполни параметры новой sub-ноды (credential, модель, режим).

Универсальный процесс добавления credential

Credential в n8n — это сохранённая «учётка» для подключения к сервису (API-ключ, OAuth-токен, логин/пароль и т.д.). Любая нода, которой нужна авторизация, выбирает credential из общего списка — поэтому добавлять его нужно один раз, а использовать можно из любого количества нод того же типа.

Пошагово

1. В левом меню n8n открой раздел Credentials.

1. Нажми кнопку Add credential (правый верхний угол).

1. В поиске введи название нужного типа credential — например, OpenAI, Header Auth, Postgres, Google — и выбери его из списка.

1. В шапке формы дай credential понятное имя — например, OpenAI школа или Postgres prod. По этому имени ты будешь выбирать его в нодах.

1. Заполни поля формы. Какие именно — зависит от типа: для API-ключевых это обычно одно поле API Key, для Header Auth — Name и Value заголовка, для Postgres — host/port/database/user/password, для OAuth — запуск OAuth-flow по кнопке.

1. Нажми Save. Готово — credential можно подключать к любой ноде, которая поддерживает этот тип.

Один URL вместо ключей всех провайдеров

LiteLLM-прокси — это единый шлюз, который принимает запросы в формате OpenAI и пересылает их к разным платным моделям: OpenAI, Anthropic, DeepSeek, Cohere и другим. Студент работает только с одним адресом и одним набором настроек.

Школа поднимает прокси, чтобы все студенты ходили через общий счёт. Школа платит провайдерам по одному договору и видит расход токенов каждого студента по отдельности. Студенту не нужно заводить личные billing-аккаунты и следить за лимитами.

OpenAI-совместимый интерфейс позволяет использовать прокси в n8n и SDK без изменений кода. Ноды и библиотеки отправляют запросы на школьный адрес, а не напрямую на api.openai.com.

Как это работает

В n8n credential OpenAi account указывает Base URL школьного прокси. Все запросы к моделям DeepSeek, Claude и остальным идут через этот credential. Модель указывается в параметре model как обычно.

Прокси не хранит модели у себя. Он только маршрутизирует запросы к внешним API и возвращает ответы. Поэтому он не заменяет self-hosted решения вроде Ollama.

Прямой ключ провайдера нужен только в двух случаях: когда требуется Assistants API или когда нужны параметры, которые прокси ещё не поддерживает. В остальных задачах весь трафик идёт через OpenAi account.

Типичные ошибки

• Считаешь OpenAi account отдельной моделью → запрос уходит не туда → выбирай имя модели из списка, который даёт школа.
• Меняешь значение model на имя из документации провайдера → модель не находится → уточняй у школы, какое имя доступно через прокси.
• Пытаешься вызвать Assistants API через прокси → запрос падает → используй прямой ключ OpenAI.
• Думаешь, что личный ключ запрещён → можно использовать, но по умолчанию весь учебный трафик должен идти через OpenAi account.
• Путаешь прокси с self-hosted моделью → ждёшь, что модели работают без интернета → LiteLLM только пересылает запросы к платным API.

Два эндпоинта к одним моделям

У OpenAI два разных эндпоинта для одних и тех же моделей: /v1/chat/completions и /v1/responses. Оба принимают запросы к gpt-4o и другим моделям, но формат запроса и ответа у них несовместим.

Chat Completions — старый и до сих пор поддерживаемый путь. Responses API — новый интерфейс, который OpenAI рекомендует для агентских сценариев.

Ключевое отличие не в модели, а в том, как ты передаёшь данные и хранишь контекст.

Как это работает

Chat Completions принимает массив messages. В ответе модель возвращает одно сообщение в choices[0].message. Всю историю разговора клиент должен хранить и отправлять заново при каждом запросе.

Responses API использует параметр input — это может быть строка или массив typed items. Поле instructions вынесено отдельно от сообщений. В ответе приходит массив typed output items (message, reasoning, function_call и другие).

Responses поддерживает stateful-цепочки через previous_response_id: OpenAI хранит предыдущие сообщения на своей стороне. Токены предыдущих запросов при этом всё равно учитываются при биллинге.

В Responses встроены инструменты Web Search, File Search и Code Interpreter — их можно включить без написания собственных функций.

В n8n-ноде OpenAI Chat Model есть переключатель Use Responses API, который меняет эндпоинт запроса. Через школьный прокси LiteLLM результат зависит от ноды, к которой подключена модель: AI Agent отвечает в обоих положениях, но с включённым переключателем n8n записывает в выполнение только оценку расхода — tokenUsageEstimate, где токены ответа модели всегда 0; Text Classifier с включённым переключателем падает на каждом элементе. С выключенным переключателем запрос идёт на /v1/chat/completions, и в выполнении виден настоящий расход — блок tokenUsage. Поэтому в задачах школы переключатель выключают всегда.

Это именно разные эндпоинты: формат Chat Completions, отправленный на /v1/responses, не сработает, и наоборот.

Типичные ошибки

• Оставили Use Responses API включённым при работе через школьный LiteLLM-прокси → у AI Agent в выполнении нет настоящего расхода токенов, только оценка с нулём на ответе, а Text Classifier падает на каждом элементе → выключи переключатель.
• Перенесли готовый воркфлоу с прямого OpenAI на прокси и не тронули тоггл → часть нод падает, у остальных пропадает настоящий расход токенов → проверь состояние переключателя в каждой OpenAI-ноде.
• Передали в запрос к /v1/chat/completions поля input, instructions или previous_response_id → ошибка валидации или поля просто игнорируются → используй только массив messages и храни историю на стороне клиента.
• Решили, что Responses API нужен только для новых моделей → gpt-4o доступен по обоим эндпоинтам, разница только в формате → не путай выбор эндпоинта с выбором модели.

Как узнать свой Telegram chat ID

chat_id — числовой идентификатор чата в Telegram. Bot API принимает его как целое число, потому что именно так хранится связь в базе Telegram и потому что username может измениться, а число — нет.

Для личных чатов твой chat_id совпадает с user_id и всегда положительный. Группы и каналы имеют отрицательный chat_id (для супергрупп начинается с -100).

Как это работает

API Telegram описывает chat_id как Integer. Значение может занимать больше 32 бит, поэтому для хранения в базе данных нужен 64-битный тип.

Получить свой chat_id можно двумя способами:

• Отправь /start боту @userinfobot — в ответе придёт твой Id.
• Открой Saved Messages в Telegram Web, в адресе после символа # будет число — это и есть chat_id.

В n8n это число вставляют в поле Chat ID ноды Telegram при отправке сообщения.

Числовой идентификатор надёжнее @username: API быстрее его обрабатывает и не зависит от смены имени пользователя. Для публичных чатов API ещё принимает строку с @username, но для личных контактов требуется именно число.

Типичные ошибки

• Подставили @username вместо числа → Bot API вернёт Bad Request: chat not found → используй только полученное числовое значение.
• Скопировали чужой пример с числовым ID → сообщения уйдут другому человеку → всегда получай chat_id одним из двух способов для своего аккаунта.
• Перепутали личный chat_id и ID группы → ID группы отрицательный, личный — положительный → проверяй знак числа перед вставкой.
• Сохранили chat_id в 32-битное поле базы данных → у части пользователей ID больше 2³¹ → используй 64-битный integer или double.

Append n8n Attribution: подпись в конце автоматических сообщений

Параметр Append n8n Attribution находится в ноде Telegram. По умолчанию он добавляет в конец каждого отправленного сообщения строку «This message was sent automatically with n8n».

Параметр спрятан: он появляется только после раскрытия Additional Fields. Значение по умолчанию — On, поэтому подпись появляется автоматически, если ничего не менять.

Зачем это нужно

Когда сообщение уходит реальному пользователю, упоминание n8n выглядит как реклама сервиса. Для тестовых и внутренних рассылок подпись иногда полезна — она сразу показывает источник. Для клиентских сообщений её отключают.

Как это работает

Параметр — простой переключатель внутри Additional Fields.

• On (включён) — в конец текста дописывается фраза «This message was sent automatically with n8n».
• Off (выключен, серый) — фраза не добавляется.

Чтобы добраться до переключателя, открой Parameters → Additional Fields → Add Field → выбери Append n8n Attribution.

Типичные ошибки

• Параметр не виден на основном экране → ищут его в Parameters → нужно раскрыть Additional Fields через Add Field.
• Оставили On для реальных пользователей → получатели видят упоминание n8n → переключи в Off, чтобы переключатель стал серым.
• Перепутали с Parse Mode → правят соседний пункт → Parse Mode отвечает за форматирование, а Append n8n Attribution — только за подпись.
• Выключили, но не проверили → подпись осталась → убедись, что переключатель серый.