Режим standby в LINE webhook: почему нет replyToken
Если событие LINE webhook содержит mode: standby, получение события ещё не означает, что ваш канал должен отвечать. Документация LINE для модульных каналов указывает: канал в режиме ожидания не должен отправлять сообщения, а его webhook-события не содержат replyToken. Это условие владения инициативой чата в Chat Control, а не признак истечения токена или сбоя доставки webhook. Сначала проверьте режим события и тип интеграции.
Главное
- Событие может успешно поступить в канал, который не отвечает за ответ пользователю.
- Отсутствие
replyTokenне должно автоматически запускать отправку push-сообщения. - Модульные каналы — специальная корпоративная возможность, а не универсальная настройка бота.
- Приём событий, ответственность за ответ и результат отправки нужно учитывать раздельно.
Что означают active и standby в LINE webhook
Официальное руководство по Messaging API для модульного канала предписывает проверять mode перед ответом. В описанной модульной конфигурации только один из подключённых каналов активен, остальные находятся в режиме standby.
| Режим события | Значение по документации | Решение приложения |
|---|---|---|
active | Канал-получатель владеет инициативой чата и может отправлять reply или push | Проверить тип события и обычные условия отправки |
standby | Канал ожидает; его события не содержат replyToken | Выполнить разрешённую внутреннюю обработку, но подавить отправку клиенту |
| Отсутствует или неизвестен | Ожидаемый контракт интеграции не подтверждён | Проверить исходное событие и парсер, не считать режим активным |
Последняя строка — рекомендуемая защитная политика, а не дополнительный режим LINE. Значение active также не означает, что любое событие содержит токен или требует ответа. Проверьте определение конкретного события в справочнике Messaging API.
Это отличается от подключения нескольких обычных инструментов к одному Messaging API channel. Чек-лист для нескольких инструментов рассматривает общие учётные данные, управление webhook и квоты. В модульной конфигурации появляется отдельный вопрос: какой канал сейчас владеет инициативой ответа?
Убедитесь, что документация Module относится к вашей интеграции
LINE описывает Module как функции для корпоративных клиентов, прошедших предусмотренную процедуру подачи заявки. Не проектируйте обычного бота в предположении, что ему доступны подключение модуля и операции Chat Control.
В руководстве Chat Control также есть предупреждение: предлагаемый сейчас модульный канал автоматически получает инициативу при подключении — Default Active — и обычно не требует ручного управления. Поэтому сама по себе эта документация не повод добавлять получение и освобождение инициативы в каждый обработчик webhook.
Сначала установите фактическую схему:
- Определите Official Account, канал-получатель и интеграцию поставщика, к которым относится запрос.
- Уточните у ответственного за интеграцию, подключён ли модуль.
- Изучите безопасно сохранённое исходное событие, а не только преобразованную запись в очереди.
- Сравните
modeи наличиеreplyTokenдо и после парсинга. - При неожиданном распределении инициативы обратитесь к поставщику модуля; не меняйте токены и webhook URL без подтверждённой причины.
Не записывайте секреты канала и токены ответа в обычные логи. Для диагностики достаточно признака наличия токена без его значения.
Сначала выясните причину отсутствия токена
Отсутствующий токен, истёкший токен и потерянный ответ на запрос отправки требуют разных действий.
| Наблюдение | Что проверить | Чего не делать |
|---|---|---|
Исходное событие имеет standby, токена нет | Инициативу чата и ожидаемый канал ответа | Создавать токен самостоятельно или автоматически отправлять push |
| В исходном событии токен есть, у воркера его нет | Парсинг, сериализацию и перенос полей в очередь | Менять инициативу ради исправления преобразования данных |
| У active-события нет токена | Схему конкретного события и контекст интеграции | Считать любой webhook пригодным для ответа |
| Токен есть, но ответ не отправляется | Фактический ответ API, историю использования и задержку обработки | Объяснять любую ошибку режимом standby |
| Запрос отправки завершился тайм-аутом | Остался ли результат принятия неизвестным | Немедленно отправлять тот же текст другой операцией |
Если токен действительно поступил, но был использован слишком поздно или повторно, переходите к руководству по ошибкам LINE reply token. Это другой сценарий, чем событие, в котором токена изначально не должно быть.
Отделите наблюдение события от права отвечать
Рекомендуемая схема приёма начинается с обычной проверки подписи и надёжного сохранения данных. В руководстве LINE по приёму webhook описаны получение и повторная доставка. Не отклоняйте корректную standby-доставку намеренно в надежде, что следующая попытка предоставит инициативу чата.
После приёма классифицируйте событие до создания задачи отправки:
- Standby: сохраните только данные, необходимые для разрешённой внутренней обработки, и отметьте, что ответ клиенту был подавлен.
- Active и событие допускает ответ: одна бизнес-операция оценивает необходимость ответа, защищается от дублей и сохраняет результат отправки.
- Контракт не подтверждён: приостановите автоматическую отправку и запросите проверку, не превращая событие в active по умолчанию.
Это решения приложения, а не дополнительные поля или статусы API LINE. Сохраняйте режим, указанный в событии. Нельзя переписать старое standby-событие как active только потому, что более позднее событие активно, или считать это новым разрешением ответить на старое сообщение.
Для отложенной работы перед отправкой сверяйтесь с текущей политикой ответственности за ответы. Если ответственный канал неясен, удерживайте отправку до проверки, а не выбирайте другую операцию. Одна лишь дедупликация событий не определяет, какой инструмент должен отвечать.
Рекомендуемые приёмочные сценарии: standby без отправки, active-событие с возможностью ответа, потеря токена в парсере, повторная доставка и задача в очереди, для которой ответственность за ответ стала неопределённой. Это предложения для тестирования, а не результаты испытаний в рабочей системе.
Где подходит UnifyPort и чего он не делает
Неофициальный интерфейс UnifyPort — отдельный путь подключения аккаунта. В справочнике авторизации LINE описаны вход по QR-коду и асинхронная передача QR URL и PIN. Это не подключение модуля и не получение инициативы чата Official Account.
В этом отдельном пути используется документированное нормализованное событие message.received. Контракт доставки webhook определяет проверку подписи при настроенном signing_secret. Не переносите предположения о нативных mode и replyToken LINE в эту схему и не представляйте отправку через UnifyPort как восстановление отсутствующего токена Official Account.
Если отправителем должен оставаться LINE Official Account, используйте официальный Messaging API и помощь ответственного поставщика модуля. Другой подключённый аккаунт не является автоматическим запасным вариантом для standby.
Вопросы и ответы
Означает ли standby, что webhook недоступен?
Нет. Событие могло поступить корректно. Standby описывает инициативу чата у канала-получателя, а не сетевое состояние сервера.
Можно ли отправить push, если нет replyToken?
Не как автоматическую замену при standby. LINE указывает, что ожидающий канал не должен отправлять сообщения. Проблема в том, кто отвечает, а не только в методе отправки.
Гарантирует ли active наличие replyToken?
Нет. Проверьте, поддерживает ли ответ конкретный тип события. Активный режим сам по себе не делает любое событие пригодным для ответа.
Каждый LINE-бот должен вызывать Chat Control?
Нет. Для Module предусмотрены специальные условия доступа, а действующая документация описывает Default Active. Сначала подтвердите реальную схему интеграции.
Следующий шаг и источники
Сравните безопасно сохранённое событие с официальным руководством для модульного канала и зафиксируйте, какой компонент отвечает пользователю. Для независимого подключения аккаунта изучите контракт авторизации LINE в UnifyPort.
Официальные материалы проверены 2026-10-27:
Превратите интеграцию сообщений в стабильный продуктовый pipeline.
Начните с отправки через единый API, затем возвращайте входящие сообщения в бизнес-систему стандартными событиями.