Перейти к содержанию

Telegram-бот на n8n: простой рецепт workflow

Обновлено: 2026-05-29

Открыть мой план

Этот рецепт показывает базовую архитектуру Telegram-бота в n8n: принять сообщение, распознать команду, ответить пользователю и сохранить лог. Для подключения credentials используйте отдельную статью n8n Telegram, здесь фокус на workflow.

Что получится

Минимальный бот умеет отвечать на /start, /help, неизвестные сообщения и передавать текст в AI-ветку. Его можно расширить до поддержки заявок, уведомлений, личного ассистента или внутреннего helpdesk.

Схема workflow

  1. Telegram Trigger принимает update.
  2. Set / Edit Fields вытаскивает chat_id, text, user_id.
  3. Switch разводит команды: /start, /help, текстовый запрос.
  4. Telegram node отправляет ответ.
  5. PostgreSQL или Google Sheets сохраняет лог сообщений.

Нормализация входа

chat_id: {{ $json.message?.chat?.id || $json.callback_query?.message?.chat?.id }}
text: {{ ($json.message?.text || $json.callback_query?.data || "").trim() }}
username: {{ $json.message?.from?.username || "unknown" }}

Команды

КомандаОтветЗачем
/startПриветствие и краткая инструкцияПервый контакт
/helpСписок командСнижение нагрузки на поддержку
Любой текстAI-ответ или fallbackОсновной сценарий
Пустой inputПросьба написать текстЗащита от нестандартных update

AI-расширение

Для GPT-ответов добавьте AI Agent или OpenAI node между Switch и Telegram node. В prompt передавайте только очищенный текст и id пользователя, а опасные инструменты подключайте только после проверки прав.

Ошибки и защита

  • Добавьте rate limit или проверку частоты сообщений для одного user_id.
  • Логируйте execution_id, chat_id и статус, но не храните лишние персональные данные.
  • Для MarkdownV2 экранируйте спецсимволы, иначе Telegram может вернуть ошибку.
  • Сделайте fallback-ветку, если AI или база недоступны.

Архитектура production workflow

Для сценария Telegram-бот на n8n: простой рецепт workflow полезно строить workflow не как одну длинную цепочку, а как понятный конвейер: вход, нормализация, проверка, основное действие, запись результата и обработка ошибок. Тогда статью можно использовать как инструкцию внедрения, а не как набор разрозненных советов.

СлойЗадачаЧто логировать
Triggerполучить событие от telegramevent_id, source, время получения
Normalizeпривести поля к единой схемеid события или записи, source, created_at, status, payload_hash
Validateотсечь пустые, повторные и рискованные входыпричину отказа и исходный payload_hash
Actionвыполнить главное действие рецептаid созданной/обновлённой записи
Notifyсообщить человеку или системе результатканал, статус, ссылка на execution

Минимальная схема данных

Не начинайте рецепт с настройки красивых уведомлений. Сначала определите контракт данных: какие поля приходят, какие обязательны, где создаётся уникальный ключ и что считается успешным результатом. Для этой статьи базовый контракт можно начать с таких полей:

  • id события или записи
  • source
  • created_at
  • status
  • payload_hash
  • chat_id или channel_id
  • message_id
  • sender

Если поля отличаются у разных источников, добавьте отдельную нормализационную ноду сразу после trigger. Это снижает количество выражений в последующих нодах и упрощает поддержку.

Проверка на реальных крайних случаях

  • пустой payload или форма без обязательного поля
  • повторная доставка одного и того же события
  • частичный успех: внешняя запись создана, но уведомление не отправилось
  • медленный API или временный 429/5xx
  • ручной повтор старого execution через неделю после первого запуска

MVP и production-версия рецепта

Рецепт Telegram-бот на n8n: простой рецепт workflow не должен конкурировать со справочником нод. Здесь важен готовый сценарий: какие ноды соединить, какие данные передать и как проверить бизнес-результат.

УровеньЧто включитьЧто пока не делать
MVPWebhook/Trigger, нормализация, основное действие, короткий ответсложные retry, multi-tenant логику, лишние ветки
Productionidempotency, error workflow, лог статусов, ручная очередь, alertхранить токены в тексте нод или логировать полный payload
Scaleочередь, лимиты, batch processing, SLA-метрикираздувать один workflow до нечитабельной схемы

Как понять, что рецепт готов

  1. Есть один владелец процесса и понятный критерий успеха: лид создан, письмо отправлено, документ сохранён, задача закрыта.
  2. Повторный запуск с тем же payload не создаёт дубль.
  3. Ошибочный payload не теряется, а попадает в manual review или alert.
  4. Все внешние API вызываются через credentials, а не через токен в plain text.
  5. К рецепту привязан готовый шаблон в разделе workflow или указано, почему шаблон не нужен.

Что читать дальше

Интеграция Telegram — здесь, AI-ассистент — здесь, ошибки авторизации — здесь.

Готовые workflow к этой теме