Home/Admin/Internal Admin API ENУКРРУС API Reference (ReDoc) ↗

Internal Admin API

Service-plane credential administration across all ownership levels, attributed to named operators.

The internal admin group /internal/v1/admin/* is the permanent entry for operator tooling — the admin panel, migration scripts. It authenticates with a service token carrying the provider-credentials.admin scope (Service Plane Tokens); user tokens do not work here, and the scope is deliberately separate in both directions from resolve: an admin token cannot read plaintext, an invoke token cannot administer. Plaintext has exactly one, separately-scoped door: Reveal.

Operator attribution: X-Admin-Actor

The calling service names the human behind each request in the X-Admin-Actor header (panel:alice; format ^[A-Za-z0-9_.:@-]{1,64}$). The label lands in the principal as service:<client_id>!<label> and from there into the audit trail's actor_id, the rate-limit key (operators do not throttle each other), and the record's updated_by. On ordinary admin operations the header is optional — the actions are reversible and self-evident in record state. On reveal it is mandatory.

Catalog for form builders

Credentials of every level, addressed by id

GET /internal/v1/admin/credentials lists across all ownership levels with filters (owner_type, owner_id, provider_code, status, is_default). POST creates with an explicit ownerplatform (no owner_id), user + UUID, or organization + UUID — the one place the API names owners in a body.

Per-record operations take just the credential_id; the owner coordinates are read from the record itself, so all the default and lifecycle invariants apply unchanged within the record's own owner scope: PATCH (rotation = whole-object replacement), make-default, disable/enable, DELETE. Masks only, everywhere.

GET /internal/v1/admin/audit-events closes the loop — the same trail as Audit Events, from the service plane.

Worked example (create a platform key as a named operator, list both planes): cookbook scenario 07.

The panel's three tabs map 1:1 onto this API

Credentials (list + create with explicit owner + per-record actions), Providers (catalog with schemas), Audit (events). If you are building another operator tool, the same three requests per screen are all you need.