Вопрос, который я задал себе и своей команде: что произойдёт, если по одному сотруднику из кадровой системы прилетят два запроса на входящий вебхук? Ответ у меня есть с 20 августа 2026 года, и он укладывается в строку: два независимых запуска, движок их между собой не связывает, ключа дедупликации нет. Ниже — что из этого следует тому, кто прямо сейчас рисует схему обмена 1С с облачным офисом.
Компанию +Альянс основал я. Руковожу ею тоже я, а по существу занимаюсь одним: тем, чтобы кадровое решение доезжало до облачного офиса без человека посередине. Инструменты в тексте остаются безымянными, и наши, и сторонние: речь про требования к приёмнику входящих запросов. Яндекс 360 упомянут как платформа, на которой живут учётные записи, и как источник, который читатель откроет сам.
Сразу про слабое место текста. Всё, что сказано ниже про поведение движка автоматизации, — моя собственная фиксация ответов, а не публичный документ, на который можно дать ссылку. Проверить это можно только на стенде, поэтому такие утверждения я даю вместе с процедурой проверки. Зато про саму платформу есть открытая документация, и на неё я опираюсь дословно. Даты такие. Каталог триггеров и действий зафиксирован 30 июля 2026, история запусков 3 августа, контракт вебхука 20 августа, страницы документации Яндекс 360 API сверены тоже 20 августа 2026.
Платформа не позвонит вам сама: в документации Яндекс 360 API подписки на события нет
Начну с того, что каждый читатель проверит за пять минут по ссылке.
Прямой адрес https://yandex.ru/dev/api360/doc/ru/concepts/webhooks отдаёт 404 Not Found, и в оглавлении документации Яндекс 360 API (https://yandex.ru/dev/api360/doc/ru/llms.txt) страницы про webhooks или подписку на события тоже нет (сверено 20 августа 2026).
Единственный документированный механизм, имеющий отношение к событиям, — аудит‑лог. И здесь нужна развилка, иначе покажется, что я спорю с самим собой. Журналов у платформы два. Узкий AuditLogService — отдельные методы по Почте и по Диску (https://yandex.ru/dev/api360/doc/ru/ref/AuditLogService/), в его перечне события про письма и файлы, создания пользователя там нет. Второй — организационный журнал audit-logs/*, общий по организации. Дальше речь только о втором.
Документация определяет его как «метод получения истории событий организации с возможностью фильтрации и постраничной навигации» (https://yandex.ru/dev/api360/doc/ru/audit-logs/index.md); для чтения нужно право ya360_security:read_auditlog. Запрос — GET https://cloud-api.yandex.net/v1/auditlog/organizations/{org_id}/events, фильтр по периоду: started_at и ended_at, причём второй параметр обязателен (https://yandex.ru/dev/api360/doc/ru/audit-logs/get-logs.md).
Событие создания пользователя в организационном журнале есть — код ya360_b2bplatform_user_created. Но получить его можно только опросом за прошедший период. Никто не постучится в ваш эндпоинт в момент, когда учётную запись создали; клиент сам ходит и спрашивает, что случилось. Такова норма платформы: механизм отдаёт историю за период по запросу. Моя оценка как проектировщика: под аудит этого достаточно, под старт провижининга — нет.
Проверьте у себя. Откройте два адреса организационного журнала, страницу AuditLogService и concepts/webhooks. Первые три открываются, последний отдаёт 404. Дальше можно не верить мне на слово ни в чём, что касается платформы.
Кадрового документа в каталоге событий нет ни у платформы, ни у движка
Аудит‑лог фиксирует то, что уже произошло с учётной записью. Приказа, заявки, кадрового решения в его перечне событий нет — и это ожидаемо: облако ведёт учётные записи и рассказывает про них, а откуда взялся человек, вне его картины мира.
У движка автоматизации, с которым я работаю, картина такая же. Триггеров восемнадцать. Пятнадцать — события самой платформы; каким образом движок про них узнаёт, я здесь не разбираю, речь только о составе перечня. В палитре они разложены по четырём категориям. Сотрудники: user_created, user_dismissed, user_blocked, user_unblocked, user_updated, department_member_created, department_member_deleted. Безопасность: disk_file_shared_public, disk_av_scan_alert, password_changed, mail_forward_created. Аудит: department_created, group_member_added. Продуктивность: созданная задача в Трекере и начатая встреча в Телемосте — кодов этих двух событий у меня нет. Семь плюс четыре плюс два плюс два, пятнадцать.
Остальные три — собственные механизмы запуска: входящий вебхук, запуск из другого потока, расписание. Ручная кнопка в счётчик триггеров не входит.
user_created для интегратора означает, что запись уже кем‑то создана. Повесив на это событие старт провижининга, вы оставляете человеку ровно ту операцию, которую хотели убрать. Профиль, отдел, группы, письмо новичку автоматика подхватит охотно. Начать процесс ей нечем. Проверить это быстрее, чем обсуждать: откройте перечень событий своего движка и поищите в нём хоть одно про кадровый документ — минута работы, и мои два абзаца вам больше не нужны.
Четыре ответа про контракт эндпоинта
Из внешней системы сценарий поднимается одним способом — HTTP‑запросом на входящий вебхук. Им же делают связку с кадровой системой: онбординг стартует при создании в 1С приказа о трудоустройстве, оффбординг ходит через тот же эндпоинт по приказу на увольнение, а второй штатный вариант для увольнения — ручной запуск оператором. На событие user_dismissed оффбординг не вешают: в этой платформе оно означает удаление учётной записи, то есть приходит по факту произошедшего.
Четыре вещи про сам контракт, зафиксированные 20 августа.
Тело запроса может быть пустым. Полезная нагрузка эндпоинту не обязательна, чтобы запустить сценарий.
Ответ эндпоинта означает факт запуска сценария. Отработка целиком — отдельное состояние, у движка для неё свои статусы завершения: ошибка, успешная отработка и другие.
Два запроса по одному человеку — два независимых запуска. Движок их не связывает, дедупликации нет.
Момент отправки задаётся на стороне 1С. При создании приказа, при проведении — выбирает тот, кто настраивает обмен в кадровой системе. Это свойство отправителя.
Проверьте у себя. Отправьте на тестовый эндпоинт пустое тело и посмотрите, стартует ли сценарий и что подставилось в поля действий. Отправьте один и тот же запрос дважды и откройте историю запусков: там должно оказаться два прогона. Заодно зафиксируйте код и тело ответа эндпоинта — это первое, что придётся разбирать обработке в 1С.
Почему запуск сценария нельзя записывать в кадровую систему как выполненную операцию
Успешный ответ эндпоинта в журнале обмена говорит одно: запрос принят, сценарий поднят. Что стало с учётной записью, из этого не следует, и разрыв тут не микросекундный.
Готовый шаблон увольнения начинается с согласования: согласующему уходит персональная ссылка на решение по почте, и до его ответа сценарий стоит. Дальше резервная копия данных увольняемого, произвольное действие заказчика и только потом удаление из тенанта. Значит, между принятым запросом и снятым доступом проходит столько, сколько согласующие не открывают почту. Отметка «доступы сняты», которую 1С поставит по ответу эндпоинта, будет неправдой.
Отсюда требование к обмену, а не факт о движке: кадровой системе нужен второй канал — тот, по которому она узнает статус завершения. Пока в схеме его нет, обмен односторонний, и называть такую связку двусторонней я бы не стал.
Дальше это удобно считать не рассказом про журнал, а таблицей полей ТЗ: что обмен вычитает со стенда, а что придётся закрывать другими средствами. Состав записи о прогоне я знаю по ответам разработчика от 3 августа 2026 года.
Поле «чем инициировано» закрывается: источник запуска в записи отдельным признаком, вебхук от расписания отличается. Поле «сколько времени заняло» тоже: длительность стоит у каждого шага. Поле «когда именно закончилось» закрывается не на уровне сценария, а внутри шага резервного копирования: у его лога есть начало и завершение с точностью до секунды, там же название копии и три счётчика: выполнено, пропущено, ошибок. Отсюда же берётся поле «сколько объектов».
Два поля, которые в задании на обмен просят первыми, со стенда не читаются. «Кто подтвердил» — в записи остаётся только результат согласующего шага, фамилии ответившего в нём нет; адресный список живёт ровно до решения, потом на его месте один признак результата. «Когда подтвердил» — такой метки в записи не сохраняется вовсе. Оба поля из схемы обмена не вытянуть, значит, в ТЗ они закрываются иначе: либо решение согласующего фиксирует у себя сама 1С, либо этих полей в обмене нет и в договорённостях так и записано.
И ограничение поверх всей таблицы: машинного канала чтения не существует, выгрузки из истории нет, всё перечисленное человек видит на экране. Мой вывод для схемы: метку времени для 1С придётся снимать со шага удаления, а не с решения согласующего, и снимать глазами.
Проверьте у себя. Поднимите сценарий с согласованием на стенде, ответьте на письмо через сутки и сравните: что показал ответ эндпоинта в момент запроса и что показала запись о прогоне после. Заодно сверьте состав записи с полями выше: всё ли из них у вас на экране и есть ли где‑нибудь кнопка выгрузки. И отдельно посмотрите, отображается ли в записи документ‑основание, ушедший во вложении письма согласующим: по ответам разработчика он в истории не показывается; речь про сам файл, а не про отсутствие выгрузки.
Где держать ключ, если приёмник его не держит
Наблюдение из моей практики проектирования обменов: в кадровом контуре один человек редко описан одним документом. Опечатка в подразделении, съехавшая дата приёма, отмена и новый номер — к моменту, когда обмен заработает, по сотруднику в базе лежит история из нескольких приказов.
Гарантия движка называется идемпотентностью необратимых действий: при повторном исполнении узла (перезапуск, повторная доставка) необратимая операция второй раз не выполняется, узел отдаёт прежний результат. Так эта гарантия сформулирована в технической документации продукта (документ от 30 июля 2026 года). Слово «узел» здесь несущее. Гарантия описана внутри одного запуска, а два запроса поднимают два запуска, и повторного исполнения узла в этой картине просто нет.
Собрать ключ внутри сценария тоже не получится — по крайней мере, штатными средствами. Действий в каталоге семнадцать, в группе «Управление сотрудниками» семь: создать, обновить, заблокировать, удалить, отозвать сессии и токены, перевести в отдел, добавить в группу. Штатного действия, которое прочитало бы каталог и поискало в нём человека, среди них нет.
Обходной путь при этом виден. В группе «Интеграции» есть действие «Исходящий HTTP‑вебхук», а подстановка умеет доставать значения из ответа вложенными путями — вплоть до {body.items[0].id}. Значит, сходить во внешний API и сравнить полученное технически можно. Сам я такую сборку не собирал и за рабочую её не выдаю. Всё это — мои выводы из состава каталога; в документации продукта таких утверждений нет.
Остаётся отправитель, и это работает в нашу пользу: момент отправки настраивается там же. Одна сторона отвечает и за «когда», и за «сколько раз». Объём работы для программиста 1С получается измеримый: одна отправка на один кадровый документ, отметка об отправке в самой базе, повторная отправка — только по решению человека. Какой там механизм внутри, я не знаю: типовая обработка, расширение, требуемая версия конфигурации остаются вопросом, и выдумывать ответ не буду.
Теперь про то, чем кончается вторая отправка на стороне платформы. Учётная запись создаётся методом POST https://api360.yandex.net/directory/v1/org/{orgId}/users (https://yandex.ru/dev/api360/doc/ru/ref/UserService/UserService\_Create.md, сверено 20 августа 2026). А вот что вернётся при попытке создать пользователя с уже занятым логином nickname, страница не говорит: отдельного кода конфликта в перечне ответов нет, про идемпотентность метода не сказано ничего. Не «платформа этого не умеет» — именно «в документации не описано».
Значит, план на этот случай строится не по документации, а руками. Страховка на приёмнике одна: у действий на холсте есть отдельный выход «Ошибка», и на него разводится хотя бы уведомление живому человеку.
Проверьте у себя. Отправьте вторым запросом того же сотрудника, что и первым, и посмотрите две вещи: код и текст ответа платформы на создание существующего пользователя и то, куда ушло управление по выходу «Ошибка». Это тот эксперимент, который стоит сделать до согласования схемы, а не после первой массовой выгрузки приказов.
Чего у меня нет
Открытые вопросы, без которых схема остаётся с белыми пятнами: состав полей непустого тела запроса; полный перечень статусов завершения сценария; код события у триггера входящего вебхука; ответ платформы на создание уже существующего пользователя (документация Яндекс 360 API на 20 августа 2026 его не описывает); сторона 1С — обработка, расширение, требуемая версия конфигурации; работающие связки у заказчиков и то, что именно у них поднимается приказом.
Главный вопрос из первой редакции этого текста закрыт, и ответ оказался неудобным: движок два приказа по одному человеку не свяжет. Значит, идентификатор кадрового документа и признак «уже отправлено» появляются в техническом задании на обмен раньше, чем первый вызов эндпоинта. Не появились — каждый повторно проведённый приказ поднимет ещё один запуск сценария, и что он сделает с учётной записью, вы узнаете уже в бою.
