Маршруты входа, учетных записей, сотрудников, ролей и личного профиля volrix.pm: права, параметры, тела запросов и примеры синхронизации.
Обновлено 27.09.2026
Группа отвечает за то, кто работает в системе и что ему разрешено: вход и сессия, учетные записи (/users), карточки сотрудников (/people), роли и их права (/admin/roles), профиль и двухфакторная аутентификация текущего пользователя (/me). Типовая задача интеграции - синхронизация с кадровой системой: завести нового сотрудника, выдать роли, заблокировать уволенного.
**Сотрудник и учетная запись.** Карточка сотрудника (/people) - это человек в оргструктуре: должность, подразделение, руководитель, центр компетенций. Учетная запись (/users) - возможность входить в систему: email, роли, блокировка, сброс пароля и 2FA. POST /people по умолчанию создает и вход (поле has_login, по умолчанию true); передайте has_login: false, если человеку вход не нужен.
Базовый адрес, формат ответов и коды ошибок описаны в статье API: адрес, первый запрос и ответы, выпуск ключа и вход под пользователем - в статье API: вход, токен и API-ключи. В примерах ключ лежит в переменной окружения VOLRIX_API_KEY, токен пользователя - в VOLRIX_TOKEN.
Поиск учетных записей по имени или email (скоуп users:read). Ответ - страница с items, total, page, page_size и pages:
curl --fail-with-body -sS \ -H "X-Api-Key: $VOLRIX_API_KEY" \ "https://ваш-адрес/api/v1/users?search=ivanov&is_active=true&page_size=50"
Создание сотрудника с входом и ролью (скоуп employees:create):
curl --fail-with-body -sS -X POST \ -H "X-Api-Key: $VOLRIX_API_KEY" \ -H "Content-Type: application/json" \ -d '{"full_name": "Петров Петр", "email": "petrov@company.ru", "position": "Инженер", "roles": ["user"]}' \ "https://ваш-адрес/api/v1/people"
Маршруты /me и /auth/me работают только в сессии самого пользователя: ключ не является пользователем, и эти маршруты его не принимают.
Как читать колонку «Доступ»: **скоуп вида users:read** - маршрут принимает API-ключ, если в ключе есть этот скоуп, а у сотрудника, выпустившего ключ, есть такое же право в роли (users.read). Если скоупов несколько через «+», нужны все. **Только сессия** - нужен заголовок Authorization: Bearer, API-ключ получит 403. **Без авторизации** - заголовки не нужны. Доступ к конкретному объекту (участие в проекте, права на папку Диска) сервер проверяет дополнительно. Пути в таблицах указаны полностью, от корня сервера.
Поля JSON и форм multipart из схемы сервера. «Да» - поле обязательно. Ссылка на другую схему (например, array[QCApproverInput]) означает вложенный объект с теми же полями.
Карточки, роли и участие в работе
Как выдать права и проверить ограничения
Правила входа и порог блокировки