Employee) — центральный ресурс API. Это карточка человека в
конкретном тенанте: скалярные поля и ссылки на связанные сущности. Получить её
можно списком GET /employees или поштучно GET /employees/{employee_id}.
Список отдаётся от новых карточек к старым.
Поля
Идентификаторы — UUID-строки, моменты времени — RFC 3339 в UTC, календарные
даты —
YYYY-MM-DD. Отсутствующие значения присутствуют в ответе (пустая строка
или null), а не пропадают из объекта. Незнакомые поля и значения enum
игнорируйте — состав ответа расширяется аддитивно.Связанные объекты
Поляperson, department, job_title и manager — это отдельные сущности,
доступные только по запросу через expand. Кастомные поля карточки тоже
приходят только по expand — см. Кастомные поля. В базовом ответе их нет, есть только
*_id-ссылки. Как обходить эти связи — на странице
Employee-graph.
person (expand=person)
department и job_title
Оба объекта — минимальные ссылки: id + title. Других полей (руководитель
отдела, иерархия, штатное расписание) в них нет.
manager (expand=manager)
Ссылка на руководителя: id + full_name. Это намеренно узкий объект — чтобы
получить полную карточку руководителя, запросите
GET /employees/{manager.id} своим ключом: так к ней применятся права и
редакция полей.
Кастомные поля
Поля, которые компания добавила в карточку сотрудника сама (размер одежды, номер пропуска, грейд), приходят вcustom_fields при expand=custom_fields.
Это объект: ключ — api_name поля, значение — JSON по типу поля. Без
expand=custom_fields объект пустой.
Каталог полей
GET /employee_custom_fields возвращает описания полей: api_name, название,
тип, варианты для списков и колонки для таблиц. Название приходит на языке из
Accept-Language, если для него есть перевод. Область та же —
employees:read.
Типы значений
В таблице
type сокращён: в ответе он приходит с префиксом
CUSTOM_FIELD_TYPE_. Незнакомые типы игнорируйте — список будет расти.
Что важно знать
- Нет ключа — нет значения. Если поле есть в каталоге, а ключа в
custom_fieldsнет, значение пустое. Полей вне каталога в карточке не бывает, даже в карточке владельца ключа. Скрытые правами поля могут быть перечислены вredacted_fieldsкакemployees.<api_name>, но опирайтесь на каталог, а не на этот список. - Файлы и изображения пока не отдаются. Поля этих типов нет ни в каталоге, ни в значениях; колонки таких типов убираются и из таблиц.
- Формульные (вычисляемые) поля не отдаются.
- Значения не переводятся. Приходит значение в том виде, в каком его ввели.
- Фильтра по кастомным полям нет. Отбирайте сотрудников на своей стороне.
- Изменения. Правка значения меняет
update_timeкарточки и отправляетemployee.changed, поэтомуupdated_sinceеё ловит. Изменение самого поля (название, варианты, видимость) карточки не трогает. Каталог и карточки читаются разными запросами, поэтому ключ, которого нет в вашей копии каталога, — повод перечитать каталог. - Только карточка сотрудника. Кастомные поля физлица (
person) пока не отдаются.
Модель доступа
Даже с областьюemployees:read ключ видит не всё. Эффективный доступ — это
пересечение областей ключа и прав владельца ключа. Область — необходимое, но не
достаточное условие: сотрудников и поля, недоступные профилю прав владельца, ключ
не увидит.
Поля, которые владелец не вправе видеть (например ИИН), в ответ не попадают, а их
ключи перечисляются в redacted_fields в формате объект.поле. Так, при
expand=person без права на ИИН:
Одиночная карточка неразличима по причине недоступности: «не существует», «нет
доступа» и «черновик/удалён» дают одинаковый
404 EMPLOYEE_NOT_FOUND. По коду
ответа нельзя выяснить, существует ли скрытый от вас сотрудник.Дальше
Employee-graph
Связи сотрудника и обход через
expand.Статусы и жизненный цикл
Значения
EmployeeStatus и переходы.Пагинация
Обход списков и инкрементальная синхронизация.