Update Credential Client Blob

PUT /api/v1/credentials/{exchange}/{wallet}/client-blob

Auth: Privy session (browser) only — an API key gets 403 privy_required.

Replaces only the browser-vault copy of an existing credential — the client_encrypted_blob that GET /credentials returns for RESTORE KEYS — with a v2 envelope. The app calls it when an unlock finds a v1 blob: it decrypts with the v1 key, re-encrypts under the v2 key (per-user vault salt) and uploads the result. The KMS-encrypted server blob that trades are executed with is untouched, and the call can never create a credential.

Request

{
  "client_encrypted_blob": "<base64 v2 envelope>",
  "client_blob_version": 2
}

Field	Description
`client_encrypted_blob`	base64 of `"SPRDR2"` ‖ 12-byte IV ‖ AES-256-GCM ciphertext+tag. The 6-byte header marks a v2 envelope, so the base64 always starts with `U1BSRFIy`. A headerless (v1) blob is rejected — the route moves blobs forward only.
`client_blob_version`	Must be `2`.

Response

200 OK

{
  "status": "updated",
  "client_blob_version": 2
}

Status	Meaning
`400`	Missing or malformed blob, `client_blob_version` other than `2`, or a blob without the v2 header (`"code": "client_blob_version"`).
`403`	The request was authenticated with an API key (`privy_required`).
`404`	No such credential on the caller's account — the route updates, never creates.

Related fields

GET /credentials reports each credential's client_blob_version: 2 for a v2 envelope, absent for a v1 blob.
POST /credentials/{exchange} accepts the same client_blob_version alongside client_encrypted_blob. The blob's header is authoritative; a declared version that disagrees with it is a 400.

Vault Salt Maintenance Status