Telegram-бот получает обновления двумя основными способами: приложение регулярно запрашивает их через long polling либо Telegram отправляет их на настроенный webhook. Выбор влияет на развёртывание, обработку сбоев и порядок переключения между серверами. Сам по себе webhook не делает сценарий умнее, а long polling не означает, что бот подходит только для опытов.
Речь в этой статье идёт именно о Telegram Bot API. Вебхуки отдельного продукта, включая собственные события Deskgram 2, имеют другой контракт, собственную авторизацию и правила повторной доставки. Их нельзя считать взаимозаменяемыми только из-за общего слова webhook.
Что меняется для приложения
При long polling приложение обращается к getUpdates и получает доступные события. Ответ может ожидать появления обновлений в пределах заданного запроса. Это отличается от частых коротких опросов, когда приложение постоянно делает пустые запросы. Для рабочего бота обычно важны корректные параметры ожидания и сохранение позиции обработки.
При webhook вы предоставляете доступный Telegram адрес HTTPS, на который приходят обновления. Приложение принимает запрос, сохраняет событие и выполняет свою логику. Появляются требования к публичной доступности, сертификату, настройкам маршрута и контролю ответа сервера. Конкретные поддерживаемые параметры смотрите в текущей документации Bot API.
Оба способа доставляют события вашему приложению. Проверка данных, сохранение состояния анкеты и защита от повторного выполнения остаются вашей задачей. Переключение транспорта не устраняет ошибку, при которой одно событие создаёт две заявки либо неудачный запрос к CRM уничтожает заполненную форму.
Когда удобнее long polling
Этот вариант удобен, если приложение уже постоянно работает на сервере, а публичный входящий адрес не нужен для других задач. Развёртывание может быть проще: не требуется публиковать отдельный обработчик обновлений. Однако процесс должен запускаться после перезагрузки, вести журнал и корректно восстанавливаться после ошибок сети.
Заранее решите, кто получает обновления. Два независимых процесса с одним токеном и несогласованной позицией могут мешать обработке. Масштабирование бизнес-логики обычно начинают с одного контролируемого входа и внутренней очереди, а не с запуска нескольких несвязанных получателей в надежде распределить нагрузку автоматически.
Long polling также удобен в тестовом окружении, где разработчик проверяет сценарий без публичного адреса. Но рабочий и тестовый бот должны быть разделены. Запуск локальной копии с рабочим токеном способен изменить поведение получения событий и создать проблемы, которые команда ошибочно примет за сбой Telegram.
Когда удобнее webhook
Webhook подходит архитектуре, где уже существует надёжный HTTPS-сервис с понятным порядком развёртывания. Его удобно включить в систему мониторинга входящих запросов и направлять принятые события в очередь работников. Важно, чтобы обработчик не зависел от долгой внешней операции до бесконечного ожидания ответа.
Проверьте путь запроса через прокси, балансировщик и приложение. Успешная главная страница сайта ещё не означает, что адрес webhook доступен правильно. Маршрут может попадать под авторизацию сайта, перенаправление, ограничение размера запроса или другое промежуточное правило. Проверка должна касаться именно входящего адреса бота.
Если используется параметр secret_token, приложение проверяет предусмотренный заголовок Telegram. Это один из элементов проверки источника запроса, а не замена контроля всех остальных условий. Не помещайте рабочий токен бота в общедоступные журналы, скриншоты или адреса страниц, которые видят сотрудники без необходимости.
Что сохранять до выполнения сценария
Для обоих способов нужна граница между получением события и его бизнес-обработкой. Сохранённое событие можно передать в очередь, а затем отметить выполненным. Если приложение аварийно завершится после получения, команда сможет понять, что осталось необработанным, вместо поиска потерянных обращений по жалобам клиентов.
Идентификатор update помогает распознавать уже полученное событие. Но защита бизнес-операций может требовать отдельного ключа. Например, два нажатия одной кнопки могут быть разными обновлениями, хотя подтверждают одну анкету. Поэтому хранение входящих событий и предотвращение двойной заявки решают связанные, но разные задачи.
У очереди должны быть понятные состояния и порядок разбора ошибок. Временная недоступность CRM не означает, что входящее сообщение недействительно. Сохраните его и повторите доставку по предусмотренному правилу. Для неисправимых случаев создайте отдельный список, который может проверить ответственный сотрудник.
Условный пример переключения
Предположим, команда переносит работающий бот с long polling на сервер приложения, где уже есть HTTPS. Сначала она поднимает и проверяет новый обработчик на отдельном тестовом боте. Затем готовит процедуру переключения рабочего получения событий и наблюдения за очередью. Сценарий не предполагает, что оба способа работают одновременно.
Перед переключением команда фиксирует состояние незавершённых обращений и останавливает прежнего получателя в согласованный момент. После установки webhook проверяет его состояние через предусмотренный API, принимает контролируемое тестовое сообщение и убеждается, что бизнес-операция выполнена один раз. Затем проверяет новые реальные обращения без изменения их содержания.
Если новый обработчик работает неверно, команда возвращает прежний способ по заранее подготовленному порядку. При этом судьба накопленных обновлений должна быть определена явно. Не используйте параметр удаления ожидающих событий просто для очистки ошибки: вместе с ними можно удалить ещё не обработанные обращения.
Как читать состояние webhook
Метод getWebhookInfo помогает проверить текущую настройку и диагностические сведения. Сопоставляйте их с журналами своего приложения. Ошибка доставки может возникнуть до входа в бизнес-логику: из-за адреса, TLS, прокси или ответа сервера. В таком случае изменение текста сообщений бота ничего не исправит.
Отдельно следите за накоплением необработанных событий. Пустой журнал ошибок не доказывает нормальную работу, если приложение вообще перестало получать запросы. Полезны контроль доступности обработчика, время последнего принятого события и проверка фактического прохождения тестового обращения по согласованному расписанию.
Не трактуйте отсутствие новых обновлений как сбой без учёта обычного потока. Для небольшого проекта длительная пауза может быть нормальной. Сигнал должен опираться на несколько признаков: состояние сервиса, доступность маршрута и ожидаемую активность, а не требовать нового клиентского сообщения каждые несколько минут.
Что проверить при откате
При возврате с webhook к long polling удалите настройку webhook предусмотренным способом и убедитесь, что старый процесс больше не конкурирует с новым. Сохраните состояние приложения и записи операций. Возврат транспорта не должен откатывать уже закрытые обращения или стирать подтверждённые заявки.
Проверьте задержанные события и повторную доставку. Старое событие может прийти после того, как сотрудник уже выполнил действие вручную. Бизнес-логика должна сверять актуальное состояние, а не слепо повторять старую команду. Особенно важно это для записи на время, выдачи доступа и других операций с последствиями.
Выбирайте способ получения по архитектуре и возможностям сопровождения команды. Надёжность подтверждается контролируемым переключением, сохранностью событий и понятным восстановлением. Разница между webhook и long polling становится управляемой, когда эти процессы описаны и проверены отдельно от пользовательского сценария бота.
Кому принадлежит настройка получения событий
Назначьте одного владельца рабочего подключения. При нескольких подрядчиках полезно явно записать, какой сервис управляет webhook и кто имеет право переключать режим. Иначе конструктор может автоматически восстановить свою настройку после ручного изменения, а другая команда будет искать причину пропавших событий в коде бота.
Перед отключением старого сервиса выясните, сохраняет ли он незавершённые анкеты и отложенные задания. Эти данные не переносятся автоматически вместе с токеном бота. Если транспорт уже переключён, а бизнес-состояние осталось в прежнем приложении, пользователь продолжит начатую форму в системе, которая ничего о ней не знает. Поэтому план переноса описывает отдельно получение обновлений, состояние сценариев и подтверждённые результаты внешних операций.
Источники
Механизмы описаны в Bot API: Getting updates, параметры подключения — в setWebhook, диагностика — в getWebhookInfo. Дополнительные пояснения доступны в официальном FAQ для разработчиков ботов.