Internal 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: один запит рендерить create-форму панелі (Provider Schemas). Адмінська ідентичність бачить усі статуси;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 називає власників у тілі.
Per-record операції беруть лише credential_id; координати власника читаються з самого запису, тож усі інваріанти default і життєвого циклу діють без змін у межах owner-scope самого запису: PATCH (ротація = заміна цілого об'єкта), make-default, disable/enable, DELETE. Усюди — лише маски.
GET /internal/v1/admin/audit-events замикає коло — та сама стрічка, що в Audit Events, із сервісної площини.
Розібраний приклад (створити platform-ключ як названий оператор, переглянути список обох площин): сценарій cookbook 07.
Три вкладки панелі лягають 1:1 на цей API
Credentials (список + створення з явним власником + per-record дії), Providers (каталог зі схемами), Audit (події). Якщо будуєте інший операторський інструмент — тих самих трьох запитів на екран вам і вистачить.