← Все статьи
Гайд

Режим 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.

Сначала установите фактическую схему:

  1. Определите Official Account, канал-получатель и интеграцию поставщика, к которым относится запрос.
  2. Уточните у ответственного за интеграцию, подключён ли модуль.
  3. Изучите безопасно сохранённое исходное событие, а не только преобразованную запись в очереди.
  4. Сравните mode и наличие replyToken до и после парсинга.
  5. При неожиданном распределении инициативы обратитесь к поставщику модуля; не меняйте токены и 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:

UnifyPort API

Превратите интеграцию сообщений в стабильный продуктовый pipeline.

Начните с отправки через единый API, затем возвращайте входящие сообщения в бизнес-систему стандартными событиями.