Overview
Если веб-хуки BroadNet для отправки отчетов о доставке (DLR) не достигают вашего сервера, причина почти всегда кроется на принимающей стороне: в учетной записи не настроен URL-адрес обратного вызова, URL-адрес недоступен публично по HTTPS или конечная точка не возвращает HTTP 200 быстро. Платформа отправляет JSON-данные DLR (MessageId, Status, BatchId и другие) на ваш URL-адрес по мере достижения каждым сообщением конечного состояния — сначала проверьте URL-адрес, ответ и ваш брандмауэр.
URL-адрес обратного вызова не настроен (или настроен неправильно).
Веб-хуки DLR срабатывают только в том случае, если в вашей учетной записи указан URL-адрес обратного вызова. Если он не настроен — или указывает на старый или неправильный хост — ничего не доставляется, и на вашей стороне не отображается никакой ошибки. Подтвердите URL-адрес DLR/веб-хука в учетной записи, а если push-уведомления не приходят совсем, получайте статус по запросу (через устаревший HTTP API: GET /websmpp/websmsstatus с идентификатором ответа).
- Для работы веб-хуков необходимо указать URL-адрес обратного вызова в учетной записи.
- Отсутствие/устаревший URL-адрес означает скрытую недоставку.
- Убедитесь, что настроенный URL-адрес DLR актуален.
- Запасной вариант: получение статуса по запросу (устаревший HTTP API: /websmpp/websmsstatus).
Конечная точка недоступна для публичного доступа по протоколу HTTPS.
Платформа отправляет POST-запросы из общедоступного интернета, поэтому localhost, частный IP-адрес, ненадежный/самоподписанный TLS-сертификат или список разрешенных IP-адресов, исключающий наших отправителей, — все это помешает отправке обратного вызова. Предоставьте общедоступную HTTPS-точку доступа с действительным сертификатом, и если вы используете список разрешенных адресов, разрешите исходящие адреса BroadNet. Проверьте URL-адрес извне вашей сети, прежде чем обвинять платформу.
- Это должен быть общедоступный HTTPS-адрес с действующим сертификатом.
- Приложения для локального хоста, частных IP-адресов и самоподписанных сертификатов не будут приниматься.
- Добавьте отправителей BroadNet в список разрешенных, если вы фильтруете входящий трафик.
- Для подтверждения доступности выполните команду `curl` для конечной точки извне вашей сети.
Конечная точка не возвращает код 200 быстро.
Ваш конечный пункт должен незамедлительно подтвердить отправку HTTP-запроса с кодом 200. Если он возвращает код 4xx/5xx, истекает время ожидания или блокируется во время выполнения ресурсоемкой операции, доставка считается неудачной и повторяется с экспоненциальной задержкой — что выглядит как «отсутствующие» или задержанные веб-хуки. Немедленно верните код 200 и обработайте запрос на доставку асинхронно (поставьте его в очередь, а затем выполните работу).
- Подтвердите получение сообщения с помощью HTTP-кода 200 (быстро).
- 5xx/4xx/таймаут → повторные попытки с задержкой (похоже на пропуски).
- Не стоит тратить время на медленную работу, прежде чем ответить.
- Верните код 200, затем обработайте DLR вне пути запроса.
Это не проблема веб-хука — сообщение ещё не окончательное.
Сообщение DLR срабатывает только тогда, когда сообщение достигает конечного состояния (DELIVRD или UNDELIV). Если сообщение все еще находится в очереди или запланировано, отчет пока не требуется — это ожидаемое состояние, а не сбой веб-перехватчика. Перед тем как сделать вывод о неисправности веб-перехватчика, подтвердите фактическое состояние сообщения с помощью запроса статуса (устаревший HTTP API: /websmpp/websmsstatus) и сопоставьте отчеты по MessageId или BatchId.
- DLR срабатывают только в конечном состоянии (DELIVRD / UNDELIV).
- Для сообщений, находящихся в очереди или запланированных к отправке, DLR пока отсутствует.
- Перед дальнейшей отладкой проверьте реальное состояние с помощью запроса статуса (устаревший HTTP API: /websmpp/websmsstatus).
- Сообщения о совпадениях отображаются по MessageId или BatchId.