Песочница

Страница для интегратора: как проверить интеграцию, не отправив ни одного сообщения живому человеку.

Как устроено

Тестовый ключ (nbh_test_…) работает против того же API, что и боевой. Отличается только исход: сообщения не уходят оператору, а получают предсказуемый результат по номеру получателя.

Данные режимов полностью изолированы. Тестовым ключом не видно боевых объектов и наоборот: попытка прочитать чужой объект даёт 404 not_found — тот же ответ, что и у несуществующего. Иначе перебором можно было бы узнать, что именно существует в бою.

Что в песочнице настоящее:

• вебхуки доставляются по-настоящему и подписываются так же;
• журнал событий, статусы, история переходов, идемпотентность, анти-флуд — всё работает как в бою;
• отказы приёма (шаблон не активен, номер не в формате, класс не включён) приходят те же.

Что отличается намеренно: в тестовом режиме допускаются шаблоны в состоянии draft и pending_moderation — интегратор не должен ждать ручной модерации у оператора, чтобы начать работу. В бою шаблон обязан быть active.

Магические номера

Таблица генерируется из той же структуры, по которой песочница себя ведёт; её же отдаёт GET /v1/sandbox/magic_numbers. Если автоматизируете сертификацию — читайте ручку, а не эту страницу.

Номер	Исход	Что проверяет
+79000000001	delivered, через ~2 с	Доставляется примерно через 2 с: счастливый путь.
+79000000002	undelivered, reason_code: handset_unreachable, через ~2 с	Не доставляется: аппарат недоступен.
+79000000003	expired, reason_code: dlr_timeout, через ~5 с	Оператор перестаёт ждать отчёт примерно через 5 с: это его срок ожидания, а не наш срок жизни.
+79000000004	422 recipient_flood_limited, с 2-й отправки	Первая отправка проходит как обычная, со второй за 5 минут срабатывает анти-флуд по получателю.
+79000000005	delivered, через ~60 с	Доставляется через 60 с: доставка не мгновенна.
+79000000006	rejected, reason_code: spam_filter_content	Оператор отклоняет сообщение синхронно: в эфир оно не уходит и не тарифицируется.
+79000000007	undelivered, reason_code: recipient_unknown, через ~2 с	Не доставляется: номера не существует.
+79000000008	delivered, через ~7 с, после повтора, attempts: 2	Оператор отказывает временно, хаб повторяет сам, сообщение доставляется со второй попытки.
+79000000009	expired, reason_code: dlr_timeout_local, отчёта не будет	Оператор молчит: сообщение остаётся отправленным до истечения срока жизни, закрывает его наш сборщик просроченных.
+79000000010	delivered, через ~2 с, плюс отметка о прочтении	Доставляется, затем приходит отметка о прочтении: прочтение статуса не меняет.
+79000000011	422 recipient_opted_out	Получатель отписан: отправка отвергается синхронно.

Остальные валидные номера дают delivered примерно через две секунды.

Боевым ключом на магический номер отправить нельзя — 422 recipient_invalid. Это намеренно: номера принадлежат выделенному оператором блоку, и боевое сообщение туда было бы отправкой в никуда.

С чего начать

1. Отправьте на +79000000001 — счастливый путь, delivered за пару секунд.
2. Проверьте +79000000002 и +79000000007 — две разные причины недоставки: ваш код должен различать их и по-разному решать, повторять ли.
3. Проверьте +79000000009 — сообщение, по которому отчёта не будет никогда: оно закроется по сроку жизни. Это самый частый случай, который забывают.
4. Проверьте +79000000004 дважды подряд — увидите анти-флуд и retry_after.
5. Заведите подписку на вебхуки и убедитесь, что проверка подписи у вас сходится: см. Вебхуки.

Все сценарии можно гонять подряд: анти-флуд на магических номерах не действует, кроме +79000000004 — того самого, ради которого он и объявлен.