Ошибки эндпоинтов LINE Messaging API: проверьте слеш в конце
Для запросов к LINE Messaging API используйте точный адрес из документации. Не добавляйте завершающий слеш и не считайте изменённый путь эквивалентным. LINE прямо предупреждает: поведение неправильных адресов, включая пути с лишним / в конце, не гарантируется. Прежде чем менять учётные данные, тело сообщения или настройки вебхука, проверьте URL, который действительно отправляет HTTP-клиент.
Главное
- Проверяйте итоговые метод, хост и путь, а не только адрес на экране настроек.
- Предупреждение LINE не обещает определённый код ошибки или перенаправление для неправильного пути.
- Адрес API и URL вашего приёмника вебхуков относятся к разным границам интеграции.
- Исправление URL не доказывает, что предыдущая отправка с тайм-аутом не состоялась.
Что LINE говорит о завершающем слеше
В уведомлении от 17 августа 2026 года LINE просит использовать точные адреса из справочника Messaging API. Лишний завершающий слеш указан прямо. Это уточнение контракта, а не сообщение о конкретном сбое или обещание универсального ответа 404.
В актуальном справочнике Messaging API перечислены следующие пути:
| Операция | Документированные метод и путь | Что не нужно добавлять |
|---|---|---|
| Отправить ответ | POST /v2/bot/message/reply | Завершающий / |
| Отправить push-сообщение | POST /v2/bot/message/push | Завершающий / |
| Получить квоту сообщений | GET /v2/bot/message/quota | Завершающий / |
Это примеры синтаксиса путей, а не взаимозаменяемые операции. Сохраняйте требования к аутентификации и телу каждого запроса. Не заменяйте ответ push-сообщением только потому, что исходный запрос завершился ошибкой.
LINE также рекомендует официальные SDK для формирования правильных URL. Однако собственный транспорт, прокси или обёртка приложения всё равно требуют проверки итогового запроса.
Аудит фактического исходящего запроса
Ниже — рекомендуемая процедура диагностики, а не перечень подтверждённых причин сбоев LINE.
- Определите операцию. Разделите вызов LINE из приложения и получение вебхука от LINE. Запишите метод и документированный адрес нужной операции.
- Проверьте сборку URL. Посмотрите настройки базового адреса, объединение путей, HTTP-узлы no-code-инструментов и общие функции, автоматически добавляющие слеш. Сравните собранное значение со справочником посимвольно.
- Проверьте последний отправляющий компонент. Если исходящий прокси или промежуточный слой переписывает пути, сравните его адрес назначения со значением приложения. Правильная настройка не исключает изменений на следующем этапе.
- Сохраните обезличенные диагностические данные. Запишите метод, хост, путь, время наблюдения, HTTP-статус и очищенный ответ об ошибке. Не сохраняйте заголовки авторизации, токены доступа, токены ответа и тексты сообщений клиентов.
- Исправьте только подтверждённое расхождение. Не меняйте одновременно ключи, получателей и URL вебхука: успешный повторный тест тогда не объяснит причину.
Не вводите глобальное правило «удалять все слеши». Сохраните разделитель хоста и структуру документированного пути, исправив сборку URL конкретной операции.
Выберите следующую проверку по оставшемуся симптому
| Наблюдение | Что проверить дальше |
|---|---|
| Итоговый путь отличается от справочника | Исправить сборку запроса и локально проверить результат |
| Метод и путь совпадают, но запрос отклонён | Фактический ответ, учётные данные и тело нужной операции |
| Verify в LINE Developers Console не проходит | Собственный URL приёмника и обработчик, а не push-эндпоинт |
| Отправка завершилась тайм-аутом | Зафиксировать неизвестный результат до решения о повторе |
Если приёмник отклоняет пустую проверочную нагрузку, используйте руководство по LINE Webhook Verify и пустому events. Это проблема входящего запроса к вашему серверу, а не лишнего слеша в адресе API LINE.
Для тайм-аута отправки с поддержкой ключа повторов есть отдельное руководство по retry key LINE. Согласно документации LINE по повторам, ключ должен присутствовать уже в первом запросе поддерживаемого метода. Исправление пути не защищает задним числом предыдущую попытку без ключа. Не повторяйте рабочее сообщение лишь для проверки формата URL.
Не смешивайте адреса LINE и UnifyPort
Неофициальный интерфейс UnifyPort использует отдельный API подключённых аккаунтов обмена сообщениями. Справочник отправки текста определяет POST /v1/messages с полями account_id, to и message и аутентификацией через X-Api-Key. Это не эндпоинт LINE Messaging API, даже если подключённый провайдер — LINE.
Проверять точные документированные адреса полезно в обеих интеграциях. Но нельзя переносить пути, учётные данные или гарантии повторов LINE в UnifyPort. Если отправителем должен быть LINE Official Account, используйте официальный Messaging API. Другая интеграция не определит, был ли принят предыдущий официальный запрос.
Регрессионные проверки и FAQ
Лишний слеш всегда вызывает 404?
В предупреждении LINE такой гарантии нет. Проверяйте фактический ответ и используйте документированный эндпоинт.
Нужно убрать слеш и из URL собственного вебхука?
Не на основании одного этого уведомления. URL приёмника должен соответствовать маршрутизации вашего сервера. Предупреждение касается запросов к Messaging API, а не всех адресов сайтов и вебхуков.
Что проверить перед выпуском исправления?
Сначала проверьте итоговые метод и URL каждой затронутой операции без реальной отправки. Охватите базовые адреса со слешем и без него, общую HTTP-обёртку и конфигурацию рабочего прокси. Если нужна сквозная проверка, используйте контролируемый аккаунт и заранее выбранную тестовую операцию. Это предлагаемые проверки, а не отчёт о выполненных тестах.
Следующий шаг и источники
Сравните один неудачный исходящий запрос со справочником LINE Messaging API. Для отдельной интеграции UnifyPort используйте контракт отправки текста.
Официальные источники проверены 2026-11-03:
Превратите интеграцию сообщений в стабильный продуктовый pipeline.
Начните с отправки через единый API, затем возвращайте входящие сообщения в бизнес-систему стандартными событиями.