Skip to navigation
HTTP APIAPI Domains

Accounts

User, Client Account, and Sub-Account management

Accounts Domain

The accounts domain manages the User → Client Account → Sub-Account hierarchy.

Entity Relationships

Client Account (Legal Entity)
├── User 1 (Login Identity)
│   ├── Access to Sub-Account A (full permissions)
│   └── Access to Sub-Account B (read only)
├── User 2 (Login Identity)
│   └── Access to Sub-Account A (trade only)
└── Sub-Accounts
    ├── Sub-Account A (Exchange)
    └── Sub-Account B (OTC)

Client Account

The legal entity holding the platform relationship.

Key Fields

FieldDescription
idUUID identifier
statusACTIVE, INACTIVE, SUSPENDED
verification_statusKYC state (see below)
typeNOMINATIVE (individual), SOCIETY (corporate)

Verification States

StateCan TradeDescription
UNVERIFIEDNoNo KYC submitted
PENDING_APPROVALNoKYC under review
VERIFIEDYesFully verified
REJECTEDNoKYC rejected

Sub-Account (Portfolio)

Segregated trading account for holding balances and executing trades.

Key Fields

FieldDescription
idUUID identifier
nameHuman-readable name
venueVENUE_MARKETPLACE (Exchange) or VENUE_OTC
pairsAllowed trading pairs (empty = all)

Why Use Multiple Sub-Accounts?

  • Segregation: Separate portfolios for different strategies
  • Access Control: Grant different users different permissions
  • Pair Restrictions: Limit trading to specific pairs
  • Reporting: Separate P&L tracking

Endpoints Overview

All endpoints below are relative to /api/rest/v1.

EndpointMethodDescription
/users/meGETCurrent user profile
/users/me/preferencesPUTUpdate preferences
/usersGETList users (if CanManage)
/client-accounts/mineGETClient account details
/sub-accounts/mineGETList accessible sub-accounts
/sub-accounts/{id}GETSub-account details

Permission Model

See Core Concepts: Permission Model for details on how actions and domains control access.