Аутентификация

Каждый запрос несёт сервисный ключ компании в заголовке X-API-Key:

curl -H "X-API-Key: odam_a1b2c3d4e5f60718_..." \
  "https://api.odamiai.uz/api/integration/v1/vacancies"

Ключ действует строго в пределах одной компании. Никакого параметра «чья компания» в API нет и не будет: компания определяется ключом, и запросить чужие данные нечем.

Как получить ключ

Ключи выпускает владелец компании (роль HRD) или администратор платформы — в интерфейсе, раздел Сервисные ключи. Рекрутёру это право не выдаётся: ключ открывает наружу всю базу кандидатов компании, и решение о такой выдаче принимает тот, кто отвечает за данные.

При выпуске указываются название и области доступа. Название нужно, чтобы через полгода было понятно, какую систему отключать.

Секрет показывается один раз

Ключ выглядит как odam_<префикс>_<секрет>. Целиком он появляется ровно один раз — в окне сразу после выпуска. Дальше в интерфейсе виден только префикс.

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

Области доступа

Область	Что открывает
vacancies:read	GET /vacancies
candidates:read	GET /candidates — персональные данные людей
applications:write	POST /applications

Метод, на который у ключа нет области, отвечает 403. Выдавайте ровно то, что системе нужно: ключ витрины вакансий с правом читать кандидатов — это утечка, которая ещё не случилась.

Отзыв

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

Отзывайте ключ, если он мог попасть в чужие руки — в репозиторий, в переписку, в логи стороннего сервиса. Ротация здесь ручная и делается парой действий: выпустить новый, перевести систему, отозвать старый.