Every balance change on an account is recorded as a movement — the most granular unit in the ledger, representing exactly one balance change.
Movements roll up into runs. A run is a group of one or more movements that all belong to the same underlying event, so a single settlement, deposit, or withdrawal can produce several movements under one run.
- Movement level → every individual debit and credit.
- Run level → the event that caused them.
Each movement carries the change itself plus the context to attribute it:
movement_id— unique identifier for the balance change.movement_type— what kind of change it is (deposit, withdrawal, execution fee, transfer, commission, and so on).- change — the signed amount the balance moved by.
account_id/asset— which account and asset it applies to.run_id— links the movement to its siblings from the same event.parent_link_id— traces the movement back to the event that created it (e.g. a specific fund event).
Together these give you a chronological, auditable trail of exactly how a balance reached its current state — the data you want for reconciliation, activity feeds, and investigating discrepancies.
Choosing the right endpoint
GET /movements — itemized movements across all accounts under your platform. Supports pagination and filtering by account, movement type, transfer type, or parent_link_id (the fastest way to pull every movement tied to a single event). Scoped to the last 2 months — built for recent activity and reconciliation, not long-range history.
GET /accounts/{account_id}/movements — the same feed, narrowed to one account. Use this when you already know the account and just want its ledger directly.
GET /accounts/{account_id}/run-history — the account's history at the run level instead of individual movements: the sequence of events that changed the balance, with their underlying movements grouped beneath each one.