Как настроить срок действия SMS через API интернет-магазина

Начните с проверки срока доставки в документации SMS-провайдера: поддерживает ли API ограничение времени, в каком формате его передавать и где оно действует. Этот срок часто называют TTL, или временем жизни сообщения. Он помогает ограничить попытки доставки, когда уведомление уже потеряло смысл. Для интернет-магазина одной настройки недостаточно: перед отправкой нужно проверить актуальность заказа, а после неё отслеживать статус SMS. Ниже разберём, как связать эти проверки и не отправлять покупателю устаревшие инструкции.

Что такое TTL в SMS и где заканчивается его действие?

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

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

TTL ограничивает доставку только в пределах возможностей сервиса и маршрута отправки. Он не удаляет SMS с телефона и не отзывает сообщение, которое покупатель уже получил. Если провайдер ограничивает лишь ожидание в собственной очереди, после передачи сообщения оператору правила могут отличаться. Это нужно уточнить до подключения.

Внутри магазина есть ещё одна очередь: события сайта или CRM ждут обработки, затем приложение обращается к SMS API. Срок доставки у провайдера не защищает от задержки в этой очереди. Поэтому сохраняйте момент, после которого уведомление теряет смысл, рядом с задачей на отправку.

Как выбрать срок доставки для разных уведомлений?

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

В таблице ниже приведены ориентиры для настройки, а не готовые значения. Конкретный срок зависит от процесса магазина и ограничений провайдера.

Сообщение	Когда текст теряет смысл	Что проверить перед отправкой
Заказ готов к выдаче	Заказ выдали, отменили или завершили хранение	Заказ ещё ожидает покупателя в нужной точке
Ожидаем оплату	Оплату приняли или возможность оплаты закрыли	Платёж ещё нужен, ссылка действительна
Курьер направляется к покупателю	Доставку завершили или перенесли	Текущий этап доставки и актуальные условия получения
Оплата подтверждена	Сообщение противоречит текущему состоянию расчётов	Подтверждение платежа и отсутствие дубля уведомления

Разделяйте срок жизни SMS и срок действия ссылки внутри него. Сообщение может прийти вовремя, но вести на страницу, где уже нельзя оплатить заказ. И обратная ситуация: ссылка ещё работает, а текст содержит старый адрес выдачи. Проверяйте оба условия отдельно.

Если заказ допускает изменение адреса, состава или времени получения, на странице по ссылке показывайте текущее состояние. Само SMS формулируйте так, чтобы оно не обещало неизменность этих данных: «Статус заказа обновлён. Условия получения доступны в заказе». Для сообщений, где адрес необходим прямо в тексте, проверяйте его непосредственно перед отправкой.

Как связать TTL с очередью магазина и SMS API?

Сначала опишите правило для одного события, например готовности к выдаче. Для базовой схемы пригодится инструкция по автоматизации SMS о статусе заказа через API. К отправке по событию добавьте проверку актуальности и обработку срока доставки.

Определите границу актуальности. Запишите, какое изменение заказа запрещает отправку, и задайте предельный момент ожидания, если его можно определить заранее.
Сохраните задачу на отправку. Свяжите её с заказом и конкретным событием, чтобы отличать новое уведомление от повторной обработки старого.
Перед обращением к API перечитайте заказ. Если статус изменился или срок истёк, завершите задачу без отправки.
Передайте доступный срок доставки. Используйте формат и единицы из документации провайдера; если API принимает длительность, рассчитывайте остаток времени на момент запроса.
Сохраните идентификатор SMS из ответа. По нему получайте результат доставки и связывайте его с исходной задачей.

Это логика интеграции, а не универсальный набор полей API. Не подставляйте название TTL наугад: сервис может использовать другое имя параметра или вообще не поддерживать нужное ограничение. Уточните также минимальный допустимый срок и поведение при значении, которое API не принимает.

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

При доработке интеграции полезно зафиксировать результат в понятном задании: какие события запускают SMS, что запрещает отправку и какие результаты видит сотрудник. Тогда подключение API включает проверку бизнес-сценария, а отчётность показывает судьбу каждого уведомления.

Как проверять статусы и отменять просроченные SMS?

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

Результаты можно получать через уведомления от провайдера или запрашивать через API, если сервис поддерживает эти способы. Для мониторинга сохраняйте время события заказа, время запроса на отправку и время получения результата. Так получится отличить задержку внутри магазина от ожидания на стороне доставки.

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

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

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

Типичные ошибки при настройке срока жизни SMS

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

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