# Тестовый режим

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

## Чем тест отличается от боя {#differences}

- Ключ `bt_test_…` видит только тестовые события, заказы, билеты и устройства. Боевой ключ их не видит, и наоборот.
- Письма по тестовым заказам уходят только на адреса сотрудников организации и подтверждённые тестовые адреса. На другие адреса письмо не отправляется, а заказ и билеты выпускаются как обычно.
- На странице тестового билета стоит плашка «ТЕСТ · билет не настоящий».
- Устройство контролёра работает в одном режиме: тестовое проверяет только тестовые события, боевое — только боевые.
- Всё остальное одинаково: те же методы, ответы, ошибки и [лимиты](https://budu.events/docs/errors/#limits).

Тестовые события в боевой режим не переносятся. К запуску создайте события заново боевым ключом.

## Тестовые адресаты {#recipients}

Адреса, на которые уходят тестовые письма, добавляют в кабинете: **настройки → тестовые адресаты → Добавить адрес**. На адрес придёт письмо со ссылкой, адрес подтвердится, когда её откроют. Адреса сотрудников организации подходят и без подтверждения. Через API список адресатов не меняется.

## Как проверить интеграцию {#checklist}

1. Создайте тестовый ключ, событие и опубликуйте его: [быстрый старт](https://budu.events/docs/).
2. Отправьте заказ на свой адрес из тестовых адресатов. Проверьте письмо и страницу билета.
3. Повторите тот же запрос с тем же `Idempotency-Key`. Должен прийти тот же заказ и заголовок `Idempotent-Replayed: true`.
4. Проверьте ответы вашего сайта на `409 sold_out`: поставьте тарифу маленькую квоту и купите больше.
5. Отмените билет через [`POST /v1/tickets/{id}/cancel`](https://budu.events/docs/tickets/#cancel): QR перестанет пускать, гостю уйдёт письмо.
6. Подключите телефон контролёра в тестовом режиме и проверьте QR на входе: [контролёры](https://budu.events/docs/devices/).
7. Замените ключ на боевой `bt_live_…` и создайте боевые события.
