Как избежать повторных SMS, если API не ответил вовремя

Сохраняйте идентификатор события до обращения к SMS API и не повторяйте отправку сразу после тайм-аута. Отсутствие ответа ещё не означает, что сервис отклонил сообщение: он мог принять запрос, пока магазин ждал подтверждения. Чтобы избежать повторных SMS, настройте проверку статуса и заранее определите, как обрабатывать запрос с неизвестным результатом. Ниже — порядок действий для интернет-магазина: как отличать новое уведомление от повтора, что сохранять в журнале и какие проверки провести перед запуском.

Почему после тайм-аута клиент получает повторное SMS?

Тайм-аут означает, что система не дождалась ответа за отведённое время. Он ничего не говорит о том, успел ли SMS-сервис принять сообщение. Например, магазин передал уведомление «Заказ готов к выдаче», сервис принял его, но ответ не дошёл до магазина. Если интеграция тут же отправит новый запрос, клиент рискует получить одинаковые сообщения.

Другой источник дублей — повторное событие внутри магазина. CRM может снова передать тот же статус после обновления карточки заказа. Такой случай отдельно отмечен в материале «Как автоматизировать SMS-статусы доставки в 2026 году» (smsinfo.by). Проверять повторы нужно ещё до обращения к SMS API.

Начните с журнала отправок. Для спорного уведомления найдите исходное событие, все попытки обращения к API и ответы сервиса. Если интеграция сохраняет только текст SMS и отметку «ошибка», по этим данным нельзя установить, принял ли сервис первый запрос.

Как отличить новое уведомление от повторной попытки?

Назначьте каждому событию постоянный ключ. Это техническая метка, по которой система узнаёт одну и ту же задачу при повторной обработке. Для уведомления о готовности заказа ключ связывает заказ, тип уведомления и конкретный переход в статус «Готов к выдаче».

Повторная попытка после тайм-аута должна использовать прежний ключ. Если при каждом обращении создавать новый, защита перестанет узнавать исходную задачу. При этом один номер заказа тоже не подходит: по заказу нужны разные сообщения, например о готовности и переносе доставки.

Предусмотрите повторные переходы между статусами. Заказ могут снять с выдачи, изменить и снова подготовить. Это уже отдельное событие, если правила магазина предполагают новое уведомление. Разработчик может различать такие события по версии статуса или идентификатору записи в истории заказа.

• Ключ события связывает уведомление с конкретным изменением заказа.
• Состояние задачи показывает, ждёт ли она отправки или проверки результата.
• Идентификатор SMS-сервиса помогает запросить статус сообщения, если ответ API его содержит.
• Журнал попыток сохраняет ответ сервиса и причину следующего действия.

Не используйте совпадение текста как единственный признак дубля. Одинаковое сообщение может относиться к разным заказам, а один и тот же запрос после правки шаблона получит другой текст. Проверять нужно связь с событием.

Как настроить повторный запрос без слепой отправки?

Уточните в документации SMS API, поддерживает ли сервис идемпотентность. Так называют обработку, при которой повтор запроса с тем же ключом не создаёт новое сообщение в пределах правил сервиса. Проверьте срок действия ключа и требования к содержимому повторного запроса. Самодельное поле с названием «ключ» не даст такой защиты, если API его не обрабатывает.

Если сервис поддерживает эту возможность, передавайте сохранённый ключ по его документации. Если такой поддержки нет, выясните, позволяет ли API искать запрос по вашей технической метке. Поиск только по идентификатору сервиса не решает проблему, когда этот идентификатор остался в ответе, который магазин не получил.

1. Создайте задачу в журнале до обращения к API. Запретите создавать ещё одну задачу с тем же ключом события.
2. Закрепите задачу за одним обработчиком, чтобы параллельные процессы не отправили её одновременно.
3. Передайте запрос и сохраните ответ вместе с идентификатором сообщения, если сервис его вернул.
4. При тайм-ауте отметьте результат как неизвестный и запустите проверку через доступный механизм API.
5. Повторяйте запрос по правилам идемпотентности либо после подтверждения, что исходный запрос не создал сообщение. Неразрешённые случаи передавайте ответственному сотруднику.

Учтите остановку приложения между отправкой запроса и сохранением ответа. После перезапуска задача останется без результата, хотя сервис уже мог принять SMS. Такая задача тоже требует проверки. Простое правило «повторить всё, что не отмечено как успешное» создаёт дубли.

Запрет параллельной обработки закрывает повторы внутри магазина, но сам по себе не устраняет неопределённость на стороне SMS-сервиса. Если API не поддерживает ни идемпотентность, ни подходящий поиск, гарантировать отсутствие дубля при автоматическом повторе нельзя. Для такого случая заранее выберите порядок ручной проверки и условие, при котором сообщение уже не следует отправлять.

Что проверить перед повторной отправкой SMS?

Сначала проверьте, актуально ли сообщение. За время ожидания заказ мог изменить статус, а покупатель — завершить действие, о котором ему собирались напомнить. Технически допустимый повтор всё равно окажется лишним, если причина уведомления исчезла.

Для SMS о брошенной корзине это означает повторную проверку оформления заказа перед обращением к API. После покупки задача должна перейти в состояние отмены, даже если раньше она ожидала повторной попытки. У сервисного уведомления проверьте текущий статус заказа: сообщение о готовности к выдаче теряет смысл после получения.

Разделяйте принятие запроса и доставку SMS. Ответ «принято» подтверждает этап работы сервиса, но не прочтение сообщения клиентом. Отсутствие статуса доставки тоже не доказывает, что запрос нужно отправлять заново. Интерпретируйте каждый статус по документации API.

Перед запуском проверьте интеграцию на тестовых заказах. Попросите разработчика воспроизвести следующие ситуации и показать записи в журнале:

• Сервис принял запрос, но магазин не получил ответ.
• CRM повторно передала одно и то же событие.
• Два обработчика одновременно взяли одну задачу.
• Приложение остановилось до сохранения ответа API.
• Заказ изменился, пока задача ожидала повторной попытки.

Проверка пройдена, если журнал объясняет судьбу каждой задачи: сервис принял сообщение, система отменила его, задача ждёт уточнения или сотрудник разбирает исключение. Отдельно проверьте, что повторное событие не создаёт новую отправку.

Типичные ошибки при защите от повторных SMS

• Считать любой тайм-аут отказом. Сохраняйте неизвестный результат отдельно от подтверждённой ошибки.
• Создавать новый ключ при каждой попытке. Закрепляйте ключ за исходным событием на весь период обработки.
• Проверять наличие задачи отдельно от её создания. Попросите разработчика обеспечить единое действие с запретом повторяющегося ключа, иначе параллельные процессы обойдут проверку.
• Бесконечно повторять запросы. Задайте условие остановки по актуальности сообщения и правилам API.
• Оставлять спорные задачи без ответственного. Выводите их в отдельный список с причиной и доступным следующим действием.

В задаче на интеграцию SMS API отдельно опишите защиту от повторов, обработку неизвестного результата и журнал событий. Для мониторинга нужны разные состояния: «сервис принял», «результат неизвестен», «отменено», «нужна проверка». Одна общая отметка «ошибка» скрывает причину и подталкивает к повторной отправке.

Начните сейчас: за две минуты добавьте в задачу разработчику вопрос «Что делает интеграция, если SMS-сервис принял запрос, но ответ не дошёл?» Попросите указать конкретное действие системы до следующей попытки.