Skip to main content
POST
Create a new wallet in a vault

Authorizations

Api-Access-Key
string
header
required

An API key associated with a security role

Path Parameters

vaultId
string
required

The ID of the vault holding the new wallet

Body

application/json
networkId
string
required

The ID of the network for assets in this wallet.

Example:

"BTC"

activateAllCompatibleNetworks
boolean

When true, activate the new wallet on every network that is key-compatible with networkId and enabled for your organization — the same set returned by compatibleNetworkIds on /asset-types — without enumerating them. Mutually exclusive with compatibleNetworkIds; supplying both is rejected with a 400.

async
boolean

When true, return 202 as soon as the creation has been durably accepted instead of blocking until the wallet exists, so no long request timeout is needed. Requires idempotencyKey: re-sending the identical request is the polling mechanism — it returns 202 while creation is still running, 200 with the wallet once it has completed, and 409 if the creation attempt failed (terminal: the key is not reusable, so retry with a new idempotencyKey). Cannot be combined with compatibleNetworkIds or activateAllCompatibleNetworks (rejected with a 400): compatible-network activation currently requires a blocking request. Ignored for fiat wallets, which are always created synchronously. Defaults to false, which keeps the blocking behavior for all existing callers.

compatibleNetworkIds
string[]

Optional list of additional compatible network IDs to activate this wallet on. All networks must share the same key family as the primary networkId. Activation on these networks happens synchronously after the initial wallet creation.

idempotencyKey
string

Optional client-provided idempotency key, scoped to your organization and to this endpoint (the same key sent to other endpoints deduplicates independently). Retrying an identical request with the same key (lost response, timeout, automated retry) returns the wallet created by the original request instead of creating a duplicate. Deduplication is bounded in time: a key is recognized only while the server retains the original request's execution history (a fixed retention window measured in days, not indefinitely), so retry promptly and never reuse a key for a different request — a key reused after the window lapses is treated as new and will create another wallet. Within the window, reuse detection is limited to what the server can observe after the fact: a key that resolves to a different vault or network is rejected with a 409. Differences in other fields (such as name) are not detected — the original request's wallet is returned — so always retry with the identical request body. A key whose creation attempt failed is also rejected with a 409: the failure is terminal for that key, so retry with a new one. With async, the key doubles as the polling handle (see async). An empty value is treated as absent. Ignored for fiat wallets: fiat wallet creation does not deduplicate retries.

Maximum string length: 128
Example:

"e763a50d-aa82-4ec7-b5a3-89ad0462d248"

subaccountId
string

The Subaccount Identifier to link this wallet.(in development / early access)

walletName
string | null

The name of the Wallet.

Example:

"Bitcoin Mainnet - Wallet 1"

Response

The new wallet info in this vault

data
WalletDetails · object
required

A wallet holds a crypto asset or fiat (USD). A crypto wallet has a depositAddress. A fiat wallet has no depositAddress. The GET endpoints return its bank wire details in depositInstruction. The create response omits depositInstruction, because the instruction is set up after the wallet is created.

Example: