# 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`

```json
{
  "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.

---

Source: https://developers.dvaarik.com/docs/providers · every page as one file: https://developers.dvaarik.com/docs.md