IOSOR

IOSOR База знань

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

Чекліст для розробників щодо переходу з sandbox на production API-ключі на prepaid white-label платформі — без подвійного білінгу, сліпих зон і витоку тестового трафіку.

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

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

Чому плутанина sandbox/production стає білінг-інцидентом

Помилка Що відбувається
Sandbox-трафік лишився вказувати на production-ключ після go-live Тестові повідомлення billяться як реальні відправлення
Production-ключ використано в load-тесті Реальний prepaid spend на синтетичний трафік
Обидва ключі активні без прапора середовища Ніхто не може пояснити, яке середовище породило який рядок інвойсу

Що відрізняє 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

Перевірте розділ ключів API у консолі IOSOR та згенеруйте окремий продакшн-токен із мінімально необхідними правами доступу. Налаштуйте вебхуки для оновлення статусів DLR на бойові ендпоінти до здійснення першої реальної розсилки. Запустіть контрольний запит через live-шлюз та відкличте тестові ключі лише після повного підтвердження логів у системі.

Підсумок IOSOR

Використання одного ключа з прапорцем середовища замість двох окремих токенів — це найкоротший шлях до списання балансу за синтетичний трафік або втрати бойових сповіщень.

Чи був матеріал корисним?

Пов’язані гіди