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
| Field | Description |
|---|---|
id | UUID identifier |
status | ACTIVE, INACTIVE, SUSPENDED |
verification_status | KYC state (see below) |
type | NOMINATIVE (individual), SOCIETY (corporate) |
Verification States
| State | Can Trade | Description |
|---|---|---|
| UNVERIFIED | No | No KYC submitted |
| PENDING_APPROVAL | No | KYC under review |
| VERIFIED | Yes | Fully verified |
| REJECTED | No | KYC rejected |
Sub-Account (Portfolio)
Segregated trading account for holding balances and executing trades.
Key Fields
| Field | Description |
|---|---|
id | UUID identifier |
name | Human-readable name |
venue | VENUE_MARKETPLACE (Exchange) or VENUE_OTC |
pairs | Allowed 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.
| Endpoint | Method | Description |
|---|---|---|
/users/me | GET | Current user profile |
/users/me/preferences | PUT | Update preferences |
/users | GET | List users (if CanManage) |
/client-accounts/mine | GET | Client account details |
/sub-accounts/mine | GET | List accessible sub-accounts |
/sub-accounts/{id} | GET | Sub-account details |
Permission Model
See Core Concepts: Permission Model for details on how actions and domains control access.
Related
Updated 5 days ago