Как заменить ключ SMS API без остановки уведомлений

Сначала проверьте, позволяет ли SMS-провайдер держать активными старый и новый ключ одновременно. Если да, замените ключ поэтапно: создайте новый, проверьте отправку, переключите приложения и только после проверки отключите старый. Так можно сохранить поток уведомлений и оставить возможность отката. Ниже — порядок действий для бизнеса, где SMS отправляют сайт, система записи или отдельный сервис. Вы сможете подготовить замену, проверить результат и разобраться, что делать, если провайдер разрешает только один ключ.

Что проверить перед заменой ключа SMS API?

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

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

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

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

Если вместо HTTP API ваша система использует SMPP-подключение, сначала уточните, какие учётные данные предстоит менять. Ключ API и пароль SMPP-сессии могут относиться к разным способам доступа. Разобраться в этой границе поможет материал о выборе между SMPP и HTTP API для небольшой SMS-интеграции.

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

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

1. Создайте дополнительный ключ. Если шлюз позволяет ограничивать права, оставьте только те операции, которые нужны приложению.
2. Добавьте новый ключ в настройки одного отправителя. Старый пока сохраните для отката в защищённом месте.
3. Отправьте тестовое SMS на доступный вам номер. Проверьте ответ API и появление сообщения в истории шлюза.
4. Переключите остальные отправители по очереди. После каждого изменения проверьте запросы и ошибки именно этого приложения.
5. Убедитесь, что рабочие уведомления проходят через новые настройки. Старый ключ пока не отключайте: сначала проверьте отложенные задания.

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

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

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

Как понять, что новый ключ работает и старый пора отключить?

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

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

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

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

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

Что делать, если провайдер допускает только один ключ?

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

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

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

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

Типичные ошибки при замене ключа SMS API

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

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