Истёк replyToken LINE? Как отвечать с задержкой без повторной отправки
replyToken в LINE Messaging API используется только один раз и должен быть применён в течение минуты после получения webhook. Позднее его работа не гарантируется. Если генерация ответа ИИ или очередь задерживает обработку, не отправляйте тот же токен снова и не переключайтесь автоматически на push после тайм-аута. Сначала отделите неиспользованный токен от ответа, который уже отправлен, но результат которого неизвестен.
Главное
- Токен ответа — краткосрочная возможность ответить, а не ID получателя или многоразовые учётные данные.
- Повторная доставка webhook не создаёт вторую независимую возможность ответа.
- Тайм-аут означает неизвестный результат, а не доказательство отсутствия отправки.
- Push — отдельная операция со своими условиями получателей и учётом сообщений, а не обновление токена.
Что LINE определяет для токенов ответа
Справочник Messaging API описывает POST /v2/bot/message/reply: запрос использует replyToken события и массив messages. Токен одноразовый, применять его следует как можно раньше. LINE также предупреждает, что срок действия может измениться. Не рассчитывайте отправлять ответ в последнюю секунду.
Даже немедленное «Проверяем ваш запрос» расходует токен. Готовый ответ позже не сможет использовать его повторно. Руководство по отправке допускает до пяти объектов сообщений в одном запросе ответа, но это не разрешение выполнить пять отдельных запросов с тем же токеном.
| Значение | Назначение | Что оно не заменяет |
|---|---|---|
| Channel access token | Аутентификация API-запроса канала | Новый токен ответа |
replyToken | Ответ на действие, вызвавшее событие | Постоянный адрес пользователя |
| Идентификатор получателя | Адресация допустимого push-получателя | Разрешение повторно использовать операцию ответа |
Если речь об уведомлении LINE MINI App, сначала прочитайте сравнение service messages и Messaging API. Токен сервисного уведомления относится к другому контракту API.
Найдите границу сбоя до выбора запасного варианта
Ниже — рекомендуемые проверки приложения, а не дополнительные коды ошибок LINE.
| Наблюдение | Что проверять | Безопасное действие |
|---|---|---|
| Воркер запустился значительно позже получения webhook | Задержка очереди или генерации | Не полагаться на старый токен; отдельно оценить отложенную отправку |
| Другой воркер уже получил успешный результат ответа | Одноразовый токен израсходован | Остановить дублирующую задачу |
| HTTP-запрос завершился тайм-аутом после отправки | Неизвестно, принят ли запрос | Сохранить неопределённость, не отправлять тот же ответ через push немедленно |
| Тот же webhook пришёл повторно | Повторный приём события | Проверить состояние исходной задачи и отправки |
| Ответ не проходит даже для нового события | Тело запроса, учётные данные канала, выбор токена или другая ошибка API | Изучить фактический ответ, а не считать любой сбой истечением срока |
Записывайте время получения webhook, запуска воркера и отправки запроса, HTTP-статус и наличие предыдущего успеха. Токены и заголовки авторизации не должны попадать в обычные логи. Храните защищённые данные токена только по необходимости для краткосрочной операции.
Одна ошибка не показывает, ответил ли уже другой воркер. Перевыпуск channel access token также не делает использованный токен ответа снова пригодным.
Повторная доставка не является обновлением токена
Руководство LINE по получению сообщений указывает, что повторная доставка сохраняет ID события и токен ответа; меняется deliveryContext.isRedelivery. Для обнаружения дублей используйте webhookEventId вместе с идентификатором канала в ключе приложения.
Справочник разрешает использовать токен повторно доставленного webhook в течение минуты после его получения, но с исключениями: токен нельзя использовать, если он уже использован или с момента события прошло 20 минут. Это ограниченная возможность при восстановлении, а не окно плановой отправки и не повод намеренно отклонять webhook.
Надёжно сохраняйте событие и подтверждайте приём отдельно от длительной обработки. Повторный webhook должен находить существующую задачу, а не запускать новую генерацию ИИ и новую отправку. Состояние отправки тоже нужно сохранять: одной дедупликации входящих событий недостаточно для задачи, повторно запущенной после сбоя воркера.
Выберите путь ответа до начала долгой задачи
Быстрым ответом должен владеть один воркер, отправляющий его без промедления. Для работы, которая может занять дольше доступного времени, заранее решите: сначала подтвердить получение и позже отправить результат либо отправить только итоговый ответ.
Рекомендуемый дизайн приложения:
- Захватывайте событие один раз. Свяжите канал и
webhookEventIdс одной бизнес-операцией. Уникальная запись или транзакционный захват предотвращает независимую отправку двумя воркерами. - Сохраняйте решение о способе отправки. Разделяйте немедленный reply и последующий push. Сообщение о принятии обращения — завершённый ответ, а не резервирование токена.
- Честно фиксируйте результат. Различайте локальные состояния «не отправляли», «принято», «отклонено» и «результат неизвестен». Это названия состояний приложения, не поля LINE. Сбой процесса после отправки также может оставить результат неизвестным.
- Проверяйте отложенную отправку. Убедитесь, что результат ещё актуален, сотрудник уже не ответил и получатель соответствует текущим условиям LINE для push. Неизвестный результат предыдущей попытки требует явного решения.
- Сохраняйте push как новую операцию. Используйте отдельный запрос и защитные меры. Push не меняет результат предыдущего reply.
Документация LINE по тарификации различает учёт сообщений: reply не включаются в количество сообщений тарифного плана, push включаются. Проверьте применимый план, а не предполагайте одинаковый учёт для запасного способа отправки.
Для поддерживаемых повторных push-запросов используйте руководство X-Line-Retry-Key. Официальная документация повторных запросов перечисляет push, multicast, narrowcast и broadcast, но не reply. Добавление этого заголовка к reply не продлевает токен и не устраняет дубли между последующим push и предыдущим ответом.
Отделяйте контракт ответа UnifyPort
Неофициальный интерфейс UnifyPort — отдельный путь через подключённый аккаунт обмена сообщениями, а не способ восстановить токен ответа LINE Official Account. Справочник текстовой отправки использует POST /v1/messages с account_id, to и message. Матрица поддержки провайдеров документирует текстовую отправку LINE, однако операция цитируемого ответа с токеном сейчас доступна только для WhatsApp.
Не передавайте LINE replyToken в UnifyPort reply_to.reply_token. Похожие имена не делают их взаимозаменяемыми. Для обычного ответа на сохранённое нормализованное событие используйте документированные идентификаторы аккаунта и беседы и проверяйте фактический результат отправки. Это не подразумевает идемпотентность между API или восстановление токена.
Если отправителем должен оставаться LINE Official Account, используйте официальный Messaging API. Смена идентичности интеграции не является безопасным автоматическим запасным вариантом при неизвестном результате официальной отправки.
Вопросы и ответы
Можно обновить истёкший токен ответа LINE?
Не обращайтесь с ним как с обновляемым access token. Новые подходящие события дают собственную возможность ответить; повторная доставка подчиняется ограничениям выше. Ни один вариант не позволяет бесконечно повторять один бизнес-ответ.
Можно сначала подтвердить получение, а потом отправить результат с тем же токеном?
Нет. Первый принятый ответ расходует одноразовый токен. Последующее сообщение нужно планировать отдельно, проверяя условия push и учёт сообщений.
Каждый тайм-аут reply должен запускать push?
Нет. Reply мог уже быть принят. Автоматический push способен продублировать его. Сохраните неизвестный результат и определите явную политику запасной отправки.
Следующий шаг и источники
Проверьте один медленный сценарий по справочнику LINE Messaging API. На локальных имитациях протестируйте повторную доставку, конкуренцию двух воркеров, подтверждение получения с последующим результатом и потерю HTTP-ответа. Это предлагаемые тесты, а не заявленные результаты эксплуатации. Для отдельного пути подключённого аккаунта начните с контракта текстовой отправки UnifyPort.
Официальные материалы проверены 2026-10-04:
Превратите интеграцию сообщений в стабильный продуктовый pipeline.
Начните с отправки через единый API, затем возвращайте входящие сообщения в бизнес-систему стандартными событиями.