POST /dapi/v1/client/accounts and kind: "sub", sending your own cl_… id in X-Hevn-Account.
A typical use is one sub account per customer of yours, each with a wallet address and account details. Your developer key signs payouts and moves from a sub account as it does for your main wallet (Signing).
Response 201, Location: /dapi/v1/client/accounts/acc_9f2c…
address accepts transfers on Base as soon as the call returns, and the wallet is deployed with the first operation it sends. Field rules are on Add an account.
Ownership
Sub accounts exist on your integrator account, which is a HEVN account: a profile plus a Base smart wallet./client/accounts requires X-Hevn-Account, so send your own id, the userId that login returns.
The developer key signs for your own wallet and its sub accounts, and for no client’s wallet, so a sub account on a client could not be spent with it. For a wallet your customer holds and signs for, register an external account. The two kinds are compared in Accounts.
A client that opened sub accounts in the HEVN app has them listed under its id on
GET /dapi/v1/client/accounts. A move from one of them through the API returns 403 account_not_controlled.
Token
A sub account holds one token on Base, set byasset at creation: USDC (the default) or RD. Any other value returns 422 validation_failed, and the token of an existing sub account cannot be changed.
Virtual accounts, payins, payouts and moves of the sub account run in that token. RD is the account key of the same name on your main wallet (Account keys), and what it changes is in RD sub accounts.
Label
label is optional, at most 64 characters, and together with asset it identifies the sub account on a retry. Use your own customer id as the label.
An
Idempotency-Key does not change the result. A body field other than kind, label and asset returns 422 validation_failed.