Арт. ALCYF
В аудит-логе Яндекс 360 задокументировано 26 типов событий — все про Почту и Диск, ни одного про появление или уход сотрудника. Разбираем, что администратор может получить из API 360, как собрать сверку через UserService_List и updatedAt и чем эту задачу закрывает «+Альянс Поток».
Коротко
- Аудит-лог Яндекс 360 документирует 26 значений
eventType: 12 про письма, 14 про файлы и доступы на Диске (сверка 2026-08-20). - Кадровых событий среди них нет: ни создания сотрудника, ни увольнения, ни блокировки, ни перевода в другой отдел.
- API 360 не документирует веб-хуки и подписку на события ни для одного из 17 своих сервисов.
- Документированный обходной путь один: опрос
UserService_List(perPageдо 1000) со сверкой поляupdatedAt. - «+Альянс Поток» даёт администратору 18 типов триггеров, включая семь кадровых, и 17 действий для Яндекс 360 и внешних систем.
С чего начинается разговор
Разговор про автоматизацию в Яндекс 360 не раз начинался у меня с одной фразы администратора: «Мне нужно, чтобы система сама узнавала, что человек пришёл или ушёл». А продолжался уверенным «в аудит-логе же всё есть».
Я тоже так думал. Название сервиса подталкивает: «история событий в организации» звучит как обещание полноты. Оказалось, обещание другое.
Ниже — разбор того, что платформа отдаёт администратору на самом деле, и того, чем закрывается разрыв между «событие произошло» и «система об этом узнала». Все цифры по платформе — из публичной документации Яндекс 360, сверка 2026-08-20, каждая проверяется по ссылке за минуту.
Что такое аудит-лог Яндекс 360
Аудит-лог Яндекс 360 — это сервис API (AuditLogService), который отдаёт историю произошедших действий в организации по запросу, отдельно для Почты и отдельно для Диска.
Ключевое слово — «произошедших». Журнал отвечает на вопрос «что было», когда его об этом спросили. Он ничего не присылает сам: инициатива всегда на стороне того, кто делает запрос.
Сколько типов событий там на самом деле
Документация Яндекс 360 API перечисляет для аудит-лога два метода и исчерпывающий список допустимых значений eventType — 26 штук на оба метода.
| Эндпоинт | Сколько типов событий | Про что события |
|---|---|---|
AuditLogService_Mail |
12 | mailbox_send, message_receive, message_seen, message_unseen, message_forward, message_purge, message_trash, message_spam, message_unspam, message_move, message_copy, message_answer |
AuditLogService_Disk |
14 | fs-copy, fs-mkdir, fs-move, fs-set-public, fs-store, fs-rm, fs-trash-append, fs-trash-drop, fs-trash-drop-all, share-activate-invite, share-change-rights, share-change-invite-rights, share-create-group, share-invite-user |
Источник: yandex.ru/dev/api360, разделы AuditLogService_Mail и AuditLogService_Disk, сверка 2026-08-20.
Двенадцать значений описывают операции с письмами: отправку, приём, чтение, пересылку, перемещение между папками, спам-метки. Четырнадцать — операции с файлами и правами доступа на Диске.
На двух строках перечня стоит задержаться: share-invite-user и share-create-group выглядят кадровыми, пока не прочитаешь описание. Первое — приглашение к общему доступу на Диске, второе — создание группы доступа к файлам. За сотрудников и группы компании в API 360 отвечают отдельные сервисы, UserService и GroupService; их операции в значения eventType аудит-лога не попадают.
Итог: события «сотрудник создан», «сотрудник уволен», «сотрудник заблокирован», «сотрудник добавлен в подразделение» в публичной документации аудит-лога Яндекс 360 на 2026-08-20 отсутствуют. Отдельного сервиса аудита оргструктуры или кадровых действий в перечне разделов API тоже нет.
Подписаться на событие тоже не получится
Раздел doc/concepts/ документации Яндекс 360 API перечисляет 17 сервисов: организации, группы, подразделения, сотрудники, внешние контакты, настройки почты сотрудников, антиспам-списки, правила обработки писем, политики домена, общие и делегированные ящики, домены, DNS-записи, двухфакторную аутентификацию, сессии, пароли, аудит-логи, сервисные приложения.
Я сверил перечень разделов doc/concepts/ 2026-08-20: разделов о лимитах запросов, квотах, веб-хуках, подписке на события и синхронизации данных в нём нет — ни одного из пяти. Справка Яндекса (yandex.ru/support) профильного материала о веб-хуках, событиях директории или интеграции HR-систем на ту же дату тоже не содержит.
Такова норма платформы, и знать её лучше на этапе проектирования. Модель API 360 — запрос-ответ: внешняя система спрашивает, платформа отвечает.
Что остаётся администратору по документации
Метод UserService_List документирует постраничную пагинацию: параметр page («номер страницы ответа», по умолчанию 1) и perPage («количество сотрудников на одной странице ответа», по умолчанию 10, максимум 1000). Курсорной пагинации в методе нет.
В ответе метода UserService_List есть поле updatedAt — «Дата и время изменения сотрудника», тип string<date-time>, пример из документации 2025-01-01T00:00:00Z.
Из этих двух фактов складывается тот самый обходной путь: опрашивать список сотрудников и сверять updatedAt со значением, сохранённым при прошлом опросе. Подчеркну границу: это возможность метода, вытекающая из состава его полей, а не рекомендация Яндекса. Текста вида «для отслеживания изменений опрашивайте List и сравнивайте updatedAt» в документации API 360 нет, в справке Яндекса — тоже. Частоту опроса, хранение снимков и логику сравнения интеграция определяет на свой страх и риск.
Ещё три детали, которые пригодятся тому, кто собирается писать такой опрос сам.
Первая: числовых лимитов запросов к API 360 в документации нет. Страница yandex.ru/dev/api360/doc/ru/concepts/limits на 2026-08-20 возвращает HTTP 404 Not Found, и в оглавлении раздела концепций её тоже нет. То есть выбрать частоту опроса «по документации» невозможно: ориентира не опубликовано.
Вторая: метод UserService_Create документирует пять кодов ответа — 400 Bad Request («Некорректный запрос»), 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error. Кода 409 Conflict в перечне нет, описание кода 400 общее и не раскрывает проверку уникальности логина. Как платформа ответит на попытку создать сотрудника с уже занятым nickname, документация не описывает — а это ровно тот случай, который возникает при повторном прогоне провижининга.
Третья: в методе UserService_Update изменяемое поле статуса — isEnabled (true — активен, false — заблокирован). Поле isDismissed («Статус сотрудника: true — уволенный, false — действующий») в теле запроса отсутствует, оно только в ответе. Прочитать статус «уволен» через API можно, записать его — нет.
Слева — модель платформы: внешняя система сама спрашивает UserService_List и сверяет updatedAt с сохранённым снимком. Справа — «+Альянс Поток»: кадровое событие срабатывает как триггер, дальше условия, действия и запись в журнале запусков.
Как эту задачу закрывает «+Альянс Поток»
«+Альянс Поток» — российский веб-сервис для автоматизации рутинных операций в организации на базе Яндекс 360. Модель работы описана документацией продукта так: администратор собирает в визуальном редакторе поток по схеме «когда происходит событие → проверить условия и выполнить действия», дальше система сама отслеживает события организации и выполняет настроенные потоки. Компания «+Альянс» поставляет «Поток» как SaaS, обработка данных — на территории РФ; данные хранятся только в собственной базе PostgreSQL, на внешние сервисы автоматизации ничего не передаётся.
Каталог триггеров «+Альянс Поток» — 18 типов: 15 событий Яндекс 360 плюс три собственных механизма запуска (входящий вебхук, запуск из другого потока, запуск по расписанию). Из этих 18 семь — ровно те кадровые события, которых администратор искал в аудит-логе:
| Триггер в палитре «+Альянс Поток» | Код события |
|---|---|
| Новый сотрудник | user_created |
| Увольнение (удаление учётной записи из Яндекс 360) | user_dismissed |
| Блокировка в Яндекс 360 | user_blocked |
| Разблокировка в Яндекс 360 | user_unblocked |
| Изменение профиля в Я360 | user_updated |
| Добавлен в отдел | department_member_created |
| Удалён из отдела | department_member_deleted |
Важная оговорка, чтобы не создавать ложных ожиданий: это внутренний каталог событий продукта, а не публично документированный механизм платформы. Проверить его состав по документации Яндекс 360 API читатель не сможет — она о нём не пишет ни в подтверждение, ни в опровержение. Источник этой таблицы — материалы владельца и палитра интерфейса «+Альянс Поток», 2026-07-30.
Действий в каталоге узлов 17, по пяти группам: коммуникации (письмо по SMTP, уведомление в Яндекс Мессенджер, событие в Яндекс Календаре), Яндекс Диск (загрузить файл, опубликовать, закрыть публичный доступ), управление сотрудниками (создать, обновить, заблокировать, удалить, отозвать сессии и токены, перевести в отдел, добавить в группу), интеграции (задача в Яндекс Трекере, исходящий HTTP-вебхук), резервное копирование (запустить бэкап пользователя, добавить пользователя в политику бэкапа).
Онбординг и оффбординг: где триггер работает, а где нет
Онбординг в «+Альянс Поток» запускается двумя способами: по триггеру создания учётной записи в Яндекс 360 («Новый сотрудник») либо входящим вебхуком из 1С при создании приказа о трудоустройстве.
С оффбордингом честнее сразу сказать про ограничение. Рабочий сценарий увольнения запускается вручную оператором или тем же входящим вебхуком из 1С по приказу на увольнение — потому что бэкап должен успеть снять данные до удаления учётной записи. Триггер «Увольнение» для сценария с полным резервным копированием не подходит, и мы не выдаём его за рабочую схему.
Порядок шагов в готовом шаблоне «Увольнение сотрудника»: согласование → бэкап сотрудника → произвольное действие клиента (в шаблоне это исходящий вебхук, например под задачу в Трекере для HR) → удаление из тенанта. Согласование блокирующее: пока согласующие не приняли решение, бэкап не запускается. Согласующему уходит персональная одноразовая ссылка по e-mail или в Яндекс Мессенджер, кворум настраивается — «Нужны все» или «Достаточно любого». В узле удаления пользователь подставляется выражением {backup.uid}, то есть шаг удаления опирается на результат шага бэкапа.
Порядок держится не на аккуратности сборщика потока, а на поведении системы: в «+Альянс Поток» есть гейтинг бэкапа — необратимые действия выполняются только после успешного завершения резервного копирования. Рядом ещё пять гарантий из документации продукта: валидация графа (невалидный поток не запускается), повторы при временных сбоях с экспоненциальной задержкой, идемпотентность необратимых действий, перезапуск с точки сбоя, ограничение одновременных запусков на организацию (документация продукта фиксирует само ограничение, числом его страница тарифов не называет).
Настройка шаблона сводится к двум вещам: подставить свои адреса согласующих и свои файлы согласования (с локального компьютера или с Яндекс Диска).
Что видно после запуска
Журнал запусков «+Альянс Поток» показывает статус, поток, триггер, шаги с длительностью, а если в потоке есть бэкап — его логи: название копии, время начала и завершения, счётчики «выполнено / пропущено / ошибок». По согласованию в записи остаётся факт пройденной ветки; файл-основание в истории не показывается. Выгрузки журнала наружу в продукте нет — это подтверждено разработчиком 2026-08-03, и лучше знать об этом до внедрения.
Лимиты тарифов
Параметры со страницы продукта plus-aliance.ru/solutions/automation/potok/, сверка 2026-08-20.
| Параметр | Старт | Бизнес | Корпоративный |
|---|---|---|---|
| Активных потоков | 5 | 25 | ∞ (fair use) |
| Редакторов в конструкторе | 2 | 10 | ∞ |
| Подключённых организаций | 1 | 1 | 3 |
| Минимальный интервал запуска по расписанию | 15 минут | 5 минут | 1 минута |
| Лимит вызовов веб-хука | 60/час на поток | 600/час на поток | 6 000/час на поток |
Статус в реестре российского ПО: «+Альянс Поток» в реестр не внесён. Из продуктов компании в реестре только «Мигратор T2T» (запись № 28672 от 09.07.2025).
Что с этим делать на своём тенанте
- Откройте
yandex.ru/dev/api360/doc/ru/ref/AuditLogService/и сверьте переченьeventTypeс датой этой статьи — 2026-08-20. Документация вендора меняется без объявления версий. - Выпишите, какие кадровые события реально нужны вашим процессам: приём, увольнение, блокировка, перевод между отделами.
- Решите, кто в вашей схеме инициатор. Либо вы пишете собственный опрос
UserService_Listсо сверкойupdatedAtи своим хранилищем снимков, либо берёте готовый каталог триггеров. - Для сценария увольнения заранее заложите ручной запуск или запуск из кадровой системы: бэкап должен успеть до удаления учётной записи.
FAQ
Есть ли в Яндекс 360 веб-хуки на события?
В публичной документации Яндекс 360 API (yandex.ru/dev/api360, сверка 2026-08-20) механизм веб-хуков, push-уведомлений или подписки на события не описан ни для одного из 17 сервисов. Справка Яндекса профильного раздела об этом на ту же дату тоже не содержит.
Сколько типов событий в аудит-логе Яндекс 360?
Двадцать шесть: 12 значений eventType в эндпоинте Почты и 14 в эндпоинте Диска. Все они описывают действия с письмами, файлами и правами доступа на Диске.
Можно ли узнать из аудит-лога, что сотрудника создали или уволили?
Нет. В документированном перечне eventType на 2026-08-20 нет ни создания пользователя, ни увольнения, ни блокировки, ни изменения подразделения. Отдельного сервиса аудита оргструктуры в перечне разделов API 360 также нет.
Как тогда отслеживать кадровые изменения через API?
Документированный путь один: периодически вызывать UserService_List (постранично, до 1000 сотрудников на страницу) и сравнивать поле updatedAt со значением из прошлого опроса. Яндекс не публикует рекомендованный паттерн такой синхронизации, поэтому частоту и логику сравнения интеграция определяет сама.
Какие лимиты запросов у API Яндекс 360?
Числовых лимитов в документации нет: страница doc/ru/concepts/limits на 2026-08-20 отдаёт HTTP 404 Not Found и отсутствует в оглавлении раздела концепций. Ориентироваться на конкретную цифру запросов в секунду не на что.
Можно ли выставить сотруднику статус «уволен» через API?
Нет. В UserService_Update изменяемое поле статуса — isEnabled (активен или заблокирован). Поле isDismissed доступно только в ответе, для чтения.
Чем «+Альянс Поток» помогает администратору Яндекс 360 в этой задаче?
«+Альянс Поток» даёт готовый каталог из 18 типов триггеров, среди которых семь кадровых («Новый сотрудник», «Увольнение», «Блокировка», «Разблокировка», «Изменение профиля», «Добавлен в отдел», «Удалён из отдела»), и 17 действий, включая семь операций управления сотрудниками и два действия резервного копирования. Кадровое событие становится точкой старта потока, а последовательность шагов гарантируется системой: необратимые действия выполняются только после успешного бэкапа.
Александр Жогов, основатель и руководитель компании «+Альянс». Все факты о платформе Яндекс 360 — по публичной документации yandex.ru/dev/api360, дата сверки 2026-08-20. Факты о продукте «+Альянс Поток» — по материалам владельца и разработчика (2026-07-30, 2026-08-03) и странице продукта (2026-08-20).
