Уведомления для команды

Приложение сообщает о сбое, а уведомление нужно всем сотрудникам эксплуатации. Иван хочет получать его в Telegram, Мария — по Email. Настроим один адрес отправки и команду получателей; способы получения каждый выберет сам.

Подготовьте организацию

Администратор создаёт организацию и приглашает Ивана и Марию. После принятия приглашений администратор или менеджер создаёт команду «Эксплуатация» и добавляет обоих в состав команды.

Создайте канал

1. В контексте организации откройте «Входящие каналы» и нажмите «Создать канал».
2. Назовите канал «События API».
3. В «Получателях» выберите команду «Эксплуатация» и сохраните.
4. Скопируйте публичный адрес канала. Для этого примера оставьте канал без шаблона и без подключённых правил.

Не указывайте в организационном канале личные адреса Ивана и Марии: получателями здесь являются сотрудники и команды.

Настройте личную доставку

Иван подключает и подтверждает Telegram, затем выбирает его для «Событий API» в разделе «Моя доставка» этой организации. Мария так же выбирает свой подтверждённый Email.

Если Мария оставит «Только в ЛК», сообщение будет доступно ей в «Моих уведомлениях», а письмо отправлено не будет. Подробности — в инструкции личной доставки.

Отправьте событие

Замените адрес на адрес созданного канала:

curl --include \
  --request POST \
  --header 'Content-Type: text/plain' \
  --data-binary 'API недоступен. Проверьте состояние сервиса.' \
  'https://depesher.ru/w/ВАШ_PUBLIC_ID'

Для защищённого канала добавьте заголовок Authorization: Bearer ВАШ_ТОКЕН.

Ожидаемый результат: HTTP 202, одно новое назначенное сообщение в «Моих уведомлениях» у каждого сотрудника и уведомление выбранным способом. Без шаблона текст имеет стандартный заголовок:

В канал «События API» поступило новое сообщение:

API недоступен. Проверьте состояние сервиса.

HTTP 202 подтверждает приём. Отдельно проверьте сообщение в Telegram и письмо, а в ЛК — состояние доставки. Неназначенный администратор не увидит это событие в своей ленте; для собственной проверки ему нужно назначение.

Проверьте изменение состава

Если Иван назначен и напрямую, и через «Эксплуатацию», запрос всё равно создаёт ему одно назначение. Два выбранных исходящих канала при этом дают две внешние отправки.

Новый участник команды получает следующие сообщения, без автоматического доступа к прежним. Снятие всех оснований назначения прекращает новые события для сотрудника. Смена его личного способа доставки не требует изменения URL в приложении.

Когда ошибки и заявки должны идти разным людям, переходите к маршрутизации JSON по событию.

Постоянный получатель и назначения из правил

Предположим, Иван должен видеть каждое событие, а Мария — только сбои и восстановления. Используйте отдельный канал «Условные события API» без шаблона. Иван и Мария остаются в команде «Эксплуатация» из первого примера.

1. В базовых получателях нового канала отметьте только Ивана напрямую.
2. Создайте правило «Сбой API»: JSON event.type → «Поле равно», тип «Строка», значение service_failed. В параметрах доставки выберите Ивана и команду «Эксплуатация».
3. Создайте правило «Восстановление API» с условием event.type = restored и доставкой команде «Эксплуатация». Преобразования, шаблон, метки и важность для этой проверки не добавляйте.
4. Сохраните и подключите оба правила, включите определения и подключения. Default для этой проверки не подключайте.
5. Иван и Мария настраивают свою «Мою доставку» для нового канала. Мария видит его только благодаря правилам; она могла бы настроить доставку и при отключённых источниках.

В настройках канала у Ивана видны «Прямое назначение» и источник «Сбой API». «Эксплуатация» показана одной строкой с двумя правилами, без раскрытия состава. Источники серые и редактируются через правила. Описание оснований относится и к личным каналам.

Проверьте три тела с Content-Type: application/json сначала в симуляции, затем отправьте их по HTTP-инструкции:

Тело	Получатели
{"event":{"type":"service_failed"},"message":"API недоступен"}	Иван и Мария. Пересечение прямого назначения, правила и команды не создаёт Ивану повторного назначения
{"event":{"type":"restored"},"message":"API восстановлен"}	Иван и Мария
{"event":{"type":"other"},"message":"Служебное событие"}	Только базовый Иван

Для каждого запроса ожидается одно новое назначенное сообщение у каждого указанного сотрудника и одна внешняя отправка в каждый выбранный им исходящий канал. Повторный HTTP-запрос остаётся отдельным событием.

Теперь откройте настройки канала, снимите у Ивана только «Прямое назначение» и сохраните. Источник «Сбой API» останется. Повторите первый и третий вход: сбой получают Иван и Мария, а служебное событие больше не назначается никому. Последний результат проверьте в симуляции: общей истории организации нет.

Отключите определение «Сбой API» либо его подключение. Источник останется с соответствующей пометкой; оба сотрудника сохранят возможность настроить «Мою доставку». После снятия базового назначения новый service_failed не назначится никому, а restored по второму включённому правилу получат оба. Включите источник снова, если хотите продолжить пользоваться этим маршрутом.

В личном канале так же проверьте пересечение на одном подтверждённом исходящем канале: выберите его базово и в правиле сбоя. Сбой даст одну отправку в этот канал; после снятия прямого назначения отправка при совпадении правила сохранится, а событие без совпадения останется только в личной истории.