Sandbox vs production keys: чеклист cutover без двойного биллинга

Тестовый ключ, оставленный живым в production-сборке, — вот как load-тест превращается в реальный инвойс. Production-ключ, вставленный в staging «просто проверить», — вот как баг из staging долетает до реальных получателей.

IOSOR по дизайну держит sandbox и production на разных ключах, разной credit posture и разных webhook target — чеклист ниже про то, что делает это разделение реально устойчивым, когда в календаре появляется настоящая дата запуска. Около USD 1 000+ месячного platform usage неудачный cutover — это не баг-репорт, а проект сверки.

Почему путаница sandbox/production становится billing-инцидентом

Что отличает sandbox-ключ от production-ключа

• Отдельная credential identity, никогда общий ключ с query-параметром «environment»
• Разные rate limits и, где уместно, разная достижимость destination
• Отдельные webhook/callback target, чтобы тестовые события никогда не долетали до production-слушателей
• Явно другой префикс или label в dashboard — не угадывание по строке ключа

Последовательность cutover без двойного биллинга

1. Заморозьте sandbox-трафик и убедитесь, что production-код нигде не ссылается на sandbox-credentials
2. Выпустите production-ключ с least-privilege scope под реально используемые типы отправок
3. Направьте webhook и callback URL на production endpoint до первой реальной отправки
4. Выполните одну реальную, намеренную отправку production-ключом и сверьте строку ledger с ожиданием точно
5. Отзовите или понизьте доступ sandbox-ключа к реальным destination после подтверждения cutover

Ротация и отзыв ключей без простоя

Ротируйте по расписанию и сразу после подозрения на утечку — но разнесите отзыв по времени: выпустите новый ключ, подтвердите на нём живой трафик, затем отзовите старый. Одновременный issue-and-revoke — вот как деплой на полпути теряет аутентификацию для реального клиентского трафика.

• Проверка подписи webhook включена в обоих окружениях, не только в production
• Достижимость destination в sandbox ограничена (только тестовые номера/домены), чтобы утёкший sandbox-ключ не мог сгенерировать реальный spend
• Rate limits в sandbox настроены ниже, чтобы быстро замечать разогнавшиеся тестовые скрипты
• Название окружения видно в каждой строке лога и во view dashboard, а не выводится только по префиксу ключа

Красные флаги

• Один общий ключ, переключаемый переменной окружения, вместо двух реальных credentials
• Проверка подписи sandbox-webhook отключена «для удобства тестирования»
• Нет записи, кто и когда выпустил какой ключ
• Production-cutover сделан без rollback-плана для sandbox-пути
• Load-тесты прогнаны на production-ключе «только в этот раз»

Начните с IOSOR

Зайдите в консоль IOSOR и выпустите отдельный продакшен-ключ с минимально необходимыми правами доступа, сохранив sandbox-ключ для изолированного тестирования. Перенаправьте вебхуки DLR и URL обратных вызовов на боевые эндпоинты перед отправкой первого реального сообщения. Проверьте логи шлюза, чтобы убедиться, что ни один сервисный запрос не использует тестовые учетные данные.

• Второй месяц API: долг по идемпотентности после первого цикла
• Анализ статусов DLR для выявления фильтрации операторами
• управление кошельком и volume review

Итог IOSOR

Использование единого ключа с флагом окружения неизбежно приводит к списаниям за синтетический трафик и утере статусов DLR.