IOSOR База знань
Day-1 runway: що має бути зеленим
Чесний day-1 runway: vault зелений, свіжий webhook heartbeat, підлога гаманця й один Live-канал зі smoke — до production-обіцянки.
Day-1 runway — найменший набір зелених сигналів для чесної production-обіцянки. Не екскурсія фічами. Чотири істини: секрети vault на місці й scoped, webhook heartbeat свіжий (stale ≡ blocked), гаманець на підлозі пілота з stop-lines, і один канал Live з delivered smoke — решта in setup.
IOSOR — white-label prepaid CPaaS. Мінімум USD 20 — підлога пілотного гаманця, не вхідний квиток. Soft review біля USD 1 000/міс — сигнал обсягу, не заміна evidence. Це не чекліст купівлі SMS API і не сусідній Гейт traffic_ok перед пілотним volume. Гроші: prepaid-резерв до першого списання. Ключі: вебхуки, що переживають запуск. Стопи: фінансові межі гаманця перед production-трафіком.
Runway — не чекліст фіч
Покупці плутають «багато продуктів» із «можна слати». Runway питає: чи можна в день один рухати реальні гроші й повідомлення, не брешучи в статусах?
| Сигнал | Зелений runway | Хибний зелений |
|---|---|---|
| Каталог | Один Live зі smoke-export | Багато плиток, нуль delivered |
| Ключі | Vault-scoped, без paste | Credentials із чату |
| Події | Свіжий HB на Live-шляху | UI зелений при stale HB |
| Гроші | Підлога + hold + стопи | Баланс є, стопів немає |
| Статуси | Blocked / in setup при red | Live заради демо |
Feature-чекліст може пройти при червоному runway. Другий канал не успадковує зелені — потрібні власні vault, HB, smoke й ledger.
Vault і ключі перед будь-яким бейджем Live
Live означає: секрети працюють без вставки API-ключів у тікети й чат. Vault-green: credentials Live-каналу на місці, scoped, rotatable, не вшиті в mobile. Не піднімайте sandbox-ключі, доки немає production-секретів.
Гігієна: verify signatures, rotate без dual-send, помилки без upstream-брендів. Блокуйте Live, якщо vault порожній або shared. Порядок: vault → smoke під pilot → production-ключі → Live. Пропуск vault дає витоки й необґрунтований burn.
Stale webhook heartbeat означає blocked
Відповідь 200 колись — не зелений runway. Heartbeat має бути свіжим: нещодавні signed events, consumer без silent drop, correlation ID = ledger. Stale ≡ blocked.
Без живого event-path продукт каже delivered, finance бачить orphan-debits, support не може replay. Вік HB — жорсткий гейт. Старіший за policy — blocked / in setup, доки smoke не поверне freshness. Fragile consumer спалить prepaid до soft review біля USD 1 000/міс.
Підлога гаманця й один чесний канал
Поповніть ≥ USD 20. Доведіть hold → outcome → settle/release. Назвіть stop-lines до production volume.
Один чесний канал = один Live з vault, свіжим HB, smoke-export, white-label статусами й ledger-рядком. Решта — in setup / coming next. П’ять Live у день один множать хибні зелені. Soft review біля USD 1 000/міс запізнілий, якщо пропущені hold, стопи чи HB.
Чекліст покупця для day-1 runway
- Vault зелений для єдиного Live-каналу — scoped, без paste?
- Heartbeat свіжий (stale ≡ blocked)?
- Гаманець ≥ USD 20 з hold → debit / release?
- Stop-lines названі й прогнані на пілоті?
- Рівно один Live зі smoke-export — решта in setup?
- Статуси white-label при red (немає fake Live)?
- Procurement окремо — buyability ≠ runway?
Будь-який red знімає обіцянку.
Почніть з IOSOR
Перед будь-яким значком Live роздрукуйте табло day-1 runway: ключі на місці й у правильній області, heartbeat вебхука не протух, гаманець бере один hold, один канал доведено до кінця. Зелена плитка продукту — не зелена смуга. Вивантажте табло з мітками часу. Це список хвірток, не екскурсія каталогом.
Підсумок IOSOR
Day-1 runway — це зелене табло, а не прогулянка функціями. Тримайте Live вимкненим, доки кожен шлюз не отримає дату й підтвердження в консолі. Не запускайте систему за продуктовим чеклістом.
Чи був матеріал корисним?
Пов’язані гіди
- Перевірка статусу реєстрації Sender ID перед запуском трафіку
Інструкція з автоматичної перевірки активності та реєстрації буквених Sender ID у цільових країнах перед стартом відправки SMS в IOSOR.
- Перевірка швидкості JIT-виділення номерів перед масштабуванням
Тестування швидкості автоматичного виділення DIDs та SLA перед запуском високого навантаження. Перевірка холдування балансу, E.164 та вебхуків в IOSOR.
- Тестування сповіщень про автопоповнення та попереджень про ліміт балансу під час запуску
Перевірка автоматичних webhook-сповіщень про низький баланс та спрацьовування автопоповнення гаманців суб-клієнтів перед запуском трафіку в IOSOR.