> For the complete documentation index, see [llms.txt](https://docs.meeco.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.meeco.me/openapi-docs/svx-api/svx-wallet-holder.md).

# SVX Wallet: Holder

The SVX Wallet part of the API is focused on personal wallet operations and credential consumption.

**Wallet management**

Holder wallet APIs (`/wallets/*`) support creating, loading, and managing multiple wallets. A wallet can be identified by an external identifier that matches an application's user identifier. When an external identifier is provided during wallet creation, the service can return an existing wallet reference instead of creating a duplicate.

**Key management**

Cryptographic keys are managed custodially by the service. Private key material is stored encrypted and does not leave the service.

Supported key operations include:

* Create key
* Delete key
* Get key
* Import key
* Sign payload
* Sign JWT
* Encrypt JWE
* Decrypt JWE

**DID management**

Wallets can manage one or more DIDs and use them for credential key binding and presentation proofs. DID usage is optional and policy/profile dependent. DID support is intended for broad method compatibility, with common methods such as did:key (including EBSI variant) and did:jwk used by default in issuance/presentation workflows where enabled.

**Credential lifecycle**

* Receive / import credential
* Verify credential
* Present credential

Receiving a credential from an issuer typically includes key binding, where the wallet provides a public key or DID and proof of control over the key material. Presenting a credential includes the credential and holder proof required by the selected presentation profile.

**Authentication and authorization**

The service does not mandate a single built-in external auth pattern for all wallets. It is expected to run behind deployment-specific controls, for example:

* API gateway policies
* Backend-for-frontend layers
* Service mesh or network perimeter controls

Depending on endpoint and deployment mode, requests may be anonymous, bearer-token protected, or mutual-TLS secured.