Проверить доступность SMS-шлюза можно без сложной диагностики: достаточно разделить путь сообщения на несколько участков и последовательно протестировать каждый. В этой статье разберём, как проверить DNS, соединение с API, авторизацию, ответ сервера и фактическую доставку SMS. Такой порядок помогает понять, где возник сбой: на сайте, в интеграции, у шлюза или на этапе передачи оператору.
Что именно нужно проверить в SMS API?
Сайт может показывать ошибку отправки, хотя сам SMS-шлюз работает. Причина бывает в неверном адресе API, истёкшем ключе, неправильном формате запроса или временной недоступности сервера. Поэтому проверка должна идти по цепочке, а не ограничиваться повторной отправкой сообщения из личного кабинета.
Для диагностики разделите отправку на пять этапов:
- домен API определяется через DNS;
- сервер сайта устанавливает HTTPS-соединение;
- шлюз принимает ключ или другой способ авторизации;
- API возвращает корректный ответ на запрос;
- шлюз передаёт SMS и сообщает итоговый статус доставки.
Последний пункт особенно важен. Ответ API обычно подтверждает, что запрос принят, но не всегда означает, что сообщение уже доставлено абоненту. Для анализа статусов пригодится разбор DLR в SMPP, где отдельно рассматриваются причины, по которым SMS не доходит до клиента: почему SMS не доходит до клиента и как читать DLR.
Как проверить доступность сервера шлюза из командной строки?
Начните с компьютера или сервера, где работает сайт. Если у вас нет доступа к консоли, эту часть может выполнить разработчик или технический подрядчик. Сначала проверьте, разрешается ли доменное имя API:
nslookup api.example.by
Вместо api.example.by укажите адрес из документации вашего шлюза. Ошибка DNS означает, что сервер не получил IP-адрес API. В таком случае проверка ключа и текста запроса пока не имеет смысла.
Следующий шаг — проверка HTTPS-соединения. Для этого используют запрос к тестовой точке API или служебному адресу, если его предоставляет шлюз:
curl -I https://api.example.by/health
В рабочей интеграции адрес и путь будут другими. Не подставляйте этот пример буквально: сначала найдите в документации шлюза endpoint для проверки состояния. Ответ с кодом сервера показывает, что соединение установлено. Ошибка сертификата, тайм-аут или отказ в соединении указывают на сетевую проблему, настройки межсетевого экрана либо ограничение на стороне API.
Если шлюз не предоставляет отдельный health-check, используйте безопасный GET-запрос к информационному endpoint. Запрос на отправку сообщения для этой проверки лучше не применять, иначе тест может создать лишнее SMS.
Как проверить запрос на отправку без повторных SMS?
После проверки соединения разберите сам запрос. В нём обычно есть адрес получателя, текст, имя отправителя, ключ доступа и технический идентификатор сообщения. Названия полей зависят от API, поэтому их берут из документации конкретного шлюза.
Проверьте четыре вещи:
- ключ передаётся в нужном заголовке или параметре;
- формат тела запроса совпадает с требованиями API, например JSON или form-data;
- номер передаётся в международном формате, если этого требует шлюз;
- текст корректно кодируется и не обрезается при отправке.
Для первой проверки выберите тестовый номер, которым вы управляете, и отправьте одно короткое сообщение. Не запускайте тест в цикле: ошибка в коде повтора способна создать несколько одинаковых SMS. Сохраните время запроса, код ответа и идентификатор сообщения. Эти три значения позволяют сопоставить запись на сайте с записью в панели шлюза.
Ответ API нужно читать по содержанию, а не только по HTTP-коду. Сервер может вернуть успешный HTTP-ответ, но передать внутри JSON сообщение об ошибке авторизации или неверном параметре. Условие интеграции должно проверять оба уровня:
| Что проверяется | Что означает результат | Следующее действие |
|---|---|---|
| HTTP-код | Сервер принял соединение и обработал запрос | Проверить тело ответа |
| Тело ответа | API подтвердил или отклонил параметры | Сохранить код и описание ошибки |
| ID сообщения | Шлюз создал запись для дальнейшей обработки | Проверить статус доставки |
| DLR или статус доставки | Сообщение передано, доставлено или отклонено | Сопоставить причину с номером и временем |
Как отличить ошибку сайта от сбоя SMS-шлюза?
Для этого проведите две отдельные проверки. Сначала отправьте тестовое SMS из панели шлюза. Затем выполните тот же сценарий через сайт или отдельный скрипт. Если панель отправляет сообщение, а сайт получает ошибку, ищите причину в интеграции: ключе, URL, формате запроса, тайм-ауте или обработке ответа.
Если сообщение не отправляется и из панели, проверьте состояние самого шлюза, доступность направления и параметры отправителя. Время сбоя зафиксируйте отдельно. Поддержке будет проще найти проблему, если передать точный момент запроса, код ошибки и ID сообщения, а не только скриншот с текстом «SMS не отправлено».
Если API принимает запрос, но клиент не получает SMS, анализируйте этап доставки. Сверьте номер, время, ID сообщения и финальный статус. Для кодов подтверждения это особенно важно: задержка или повторная отправка может привести к тому, что пользователь введёт уже устаревший код. В сценариях OTP канал выбирают с учётом страны, устройства и задачи входа; сравнение SMS и Viber для OTP-кодов разобрано в отдельном материале: как выбрать канал доставки OTP-кодов.
Как организовать регулярную проверку API?
Разовая проверка помогает найти текущую ошибку, но не показывает, повторяется ли проблема. Для сайта полезно настроить технический контроль с безопасным запросом к health-check либо к тестовому endpoint. Если такой возможности нет, проверяйте интеграцию вручную перед важным запуском: регистрацией пользователей, изменением сайта или подключением нового сценария уведомлений.
В журнале интеграции храните технические поля, которые нужны для поиска ошибки:
- дата и время запроса;
- название сценария, например «код входа» или «статус заказа»;
- HTTP-код и внутренний код ответа API;
- идентификатор сообщения;
- результат обработки статуса доставки;
- время ожидания ответа и число повторов.
Текст SMS в журнал лучше не дублировать без необходимости. Для диагностики обычно достаточно шаблона сообщения и его технического ID. Такой подход уменьшает объём записей и помогает отделить служебную информацию от содержимого уведомления.
Для повторных попыток задайте ограничение. Если сайт повторяет запрос после любого тайм-аута, один пользователь может получить несколько одинаковых сообщений. Перед повтором проверьте, есть ли у API ключ идемпотентности или возможность запросить статус уже созданного сообщения. Если такой функции нет, сначала уточните состояние операции через журнал шлюза.
Какие ошибки при проверке SMS API встречаются чаще всего?
- Проверяют только панель шлюза. Сайт может использовать другой ключ, endpoint или формат запроса.
- Считают HTTP 200 гарантией доставки. Этот код часто подтверждает только обработку запроса сервером.
- Повторяют отправку вручную много раз. Так сложно понять причину, а тестовые SMS начинают дублироваться.
- Не записывают ID сообщения. Без него трудно сопоставить запрос сайта со статусом в шлюзе.
- Не учитывают тайм-аут. Сайт может прекратить ждать ответ, хотя шлюз уже принял сообщение.
- Смешивают ошибки авторизации и доставки. Неверный ключ исправляют в интеграции, а недоставленный номер анализируют по DLR.
3 шага, которые можно сделать сегодня:
- Проверить DNS и HTTPS-соединение с API со стороны сервера сайта.
- Отправить одно тестовое сообщение и сохранить HTTP-код, ответ API и ID.
- Сверить финальный статус доставки и записать причину ошибки в журнал интеграции.
Если сайт регулярно отправляет статусы заказа, уведомления об отмене или коды входа, проверяйте каждый сценарий отдельно. Для интернет-магазина полезно заранее разобрать, как автоматизировать SMS-статусы доставки заказа: там важны не только вызов API, но и переходы между статусами. Такой порядок позволяет понять, где нужна настройка сайта, а где стоит обратиться к владельцу SMS-шлюза.