Внутренний 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 (события). Если вы строите другой операторский инструмент — те же три запроса на экран, и этого достаточно.