Provider accounts

Render from the server catalogue#

GET /v2/provider-catalog with an account JWT returns provider IDs, labels, capabilities (stt, llm, tts, realtime), credential fields and alternatives, model IDs, and provider pricing links. Treat it as the source of truth. Do not copy model or secret-field lists into an application.

The catalogue describes shape only. It never reads configured credentials and never calls a provider.

Save, verify, use#

Console: POST /console/v2/projects/{project_id}/provider-accounts

{
  "provider": "<catalogue id>",
  "name": "Production account",
  "credentials": { "<catalogue field>": "<secret>" }
}

A save validates the exact shape and encrypts the secret; the account is configured. POST .../provider-accounts/{account_id}/probe asks the provider: a confirmed credential becomes verified (with verified_at), a rejected one invalid (with last_error), and a transient provider failure stays configured so an uncertain probe never admits a call. The console runs the probe right after saving. Only verified accounts are accepted in an agent's pipeline and at session admission.

Safe responses contain id, project_id, provider, name, capabilities, a masked hint, status, safe error, revision, key version, verification timestamp, and ordinary timestamps. They never contain credential material. POST .../rotate re-encrypts the stored secret under the current keyring key without changing the credential.

Server applications may use /v2/provider-accounts with the corresponding project-key scopes; browsers must not.