Главная/Администрирование/Внутренний Admin API ENУКРРУС API-справочник (ReDoc) ↗

Внутренний Admin API

Администрирование credentials с сервисной плоскости на всех уровнях владения, с атрибуцией названным операторам.

Внутренняя админ-группа /internal/v1/admin/* — постоянный вход для операторского инструментария: админ-панели, миграционных скриптов. Она аутентифицируется сервисным токеном со scope provider-credentials.admin (Service Plane Tokens); пользовательские токены здесь не работают, а scope намеренно отделён в обе стороны от resolve: админский токен не может читать plaintext, invoke-токен не может администрировать. У plaintext ровно одна отдельно скоупленная дверь: Reveal.

Атрибуция оператора: X-Admin-Actor

Вызывающий сервис называет человека за каждым запросом в заголовке X-Admin-Actor (panel:alice; формат ^[A-Za-z0-9_.:@-]{1,64}$). Метка попадает в принципала как service:<client_id>!<label>, а оттуда — в actor_id audit-ленты, в ключ лимита запросов (операторы не троттлят друг друга) и в updated_by записи. На обычных админ-операциях заголовок опционален — действия обратимы и самоочевидны в состоянии записи. На reveal он обязателен.

Каталог для построителей форм

  • GET /internal/v1/admin/providers — каждый провайдер с вендором, разрешениями по уровням и обеими JSON Schema: один запрос рендерит форму создания панели (Provider Schemas). Админская identity видит все статусы; include_removed=true добавляет removed.
  • GET .../providers/{code} и .../credential-usage — представления детали и использования, любой статус.

Credentials любого уровня, адресуемые по id

GET /internal/v1/admin/credentials перечисляет по всем уровням владения с фильтрами (owner_type, owner_id, provider_code, status, is_default). POST создаёт с явным владельцемplatform (без owner_id), user + UUID или organization + UUID — единственное место, где API называет владельцев в теле.

Позаписные операции берут только credential_id; координаты владельца читаются из самой записи, так что все инварианты default и жизненного цикла действуют без изменений в рамках собственного owner-scope записи: PATCH (ротация = замена объекта целиком), make-default, disable/enable, DELETE. Только маски, везде.

GET /internal/v1/admin/audit-events замыкает круг — та же лента, что в Audit Events, с сервисной плоскости.

Разобранный пример (создать платформенный ключ как названный оператор, перечислить обе плоскости): сценарий cookbook 07.

Три вкладки панели ложатся 1:1 на этот API

Credentials (список + создание с явным владельцем + позаписные действия), Providers (каталог со схемами), Audit (события). Если вы строите другой операторский инструмент — те же три запроса на экран, и этого достаточно.