POST /accounts accepts three optional discriminator fields that determine how Brale verifies the account and what it can do:
Omitting all three dimension fields produces exactly today’s behavior. Existing integrations that create business accounts do not need to change.
Supported combinations
Only three combinations are accepted:
Any other combination is rejected with
422 unsupported_account_combination. The rejection is permanent, so it is safe for clients to cache the error against an idempotency key.
There is no individual + custodial combination and no business + transactional combination.
When to choose each
- Business, custodial, standard — a business entity that will hold stablecoin balances in Brale-custodied wallets, initiate transfers, and use Brale as its record of funds. See Custodial Accounts.
- Individual, transactional, standard — a natural person who receives value on-chain (for example, as the destination of an on-ramp) but does not hold custody with Brale. See Individual accounts.
- Individual, transactional, reliance — the same shape as the standard individual path, verified under a reliance model. Use this when your integration operates under an agreement with Brale that specifies reliance.
Backward compatibility
The dimension fields are optional and default to the values that describe today’s account. A request that omitsentity_type, account_type, and verification_mode continues to create a KYB-verified business account with Brale-custodied wallets, exactly as before.
Related
- Accounts — the full account resource, fields, and lifecycle.
- Individual accounts — end-to-end workflow for creating and using a transactional account.
POST /accounts— API reference.