Skip to main content
getApplicationConfig is session-authenticated (call it after a user logs in). The six reporting methods are public: they need no session or key, and each selects its application by clientId — the same public client ID your frontend logs in with. An unknown or inactive client ID returns 404, and so does the client ID of a builder the explorer hides: the reporting methods follow the same builder display rules as the explorer and the public analytics, and a hidden builder reads exactly like one that does not exist. A builder shown as part of a group is still reported as itself. The reporting methods are rate limited per client IP: 60 requests per minute sustained, with a burst of 120. Over the limit the API returns 429 with a Retry-After header.
​
() => Promise<ApplicationConfigResponse>
Retrieve application configuration for the current client ID. Session-authenticated.Returns: ApplicationConfigResponse:
  • id: string — application UUID
  • name: string — application name
  • allowedOrigins: string[] — CORS-allowed origins
  • webhookUrl?: string — webhook URL for event delivery
  • vaultContractAddress: string — vault contract address for this application
  • clientId: string — application client ID, embedded in on-chain deposit calls
​
(params: ListAppOrdersParams) => Promise<ListAppOrdersResponse>
List orders placed by the application’s users. Public.Parameters:
  • params: ListAppOrdersParams
    • clientId: string — the application’s public client ID (required)
    • pageSize?: number — items per page, 1 to 1000 (default 20); a larger value is rejected
    • pageToken?: string — cursor pagination. Omitted or "" starts the walk; otherwise pass the previous response’s nextPageToken. There is no page: the SDK rejects one with a ValidationError before sending, and a raw REST request carrying it gets 400. The filters must match the request that minted the token
    • status?: string — filter by order status (e.g. SUBMITTED, PARTIALLY_FILLED, FILLED, SETTLED, CANCELLED, EXPIRED, REJECTED)
    • userId?: string — filter by user UUID
    • tradingPairId?: string — filter by trading pair UUID
    • side?: string — filter by side: BUY or SELL
    • orderType?: string — filter by order type (e.g. LIMIT, MARKET, STOP_LOSS, TAKE_PROFIT, STOP_LIMIT, TRAILING_STOP)
Returns: ListAppOrdersResponse:
  • orders: AppOrder[] — matching orders
  • pageSize: number — items per page
  • nextPageToken: string — cursor for the next page, "" once the walk is exhausted. Each page over-fetches one row, so an empty token is definitive: follow a non-empty token, stop on an empty one
No item count: this listing spans the hot order table and the archive, so counting behind a filter would walk the application’s whole lifetime prefix on every page.The read has a 3-second budget: one that cannot finish in time fails with 503 instead of running long. Narrow the filters or retry later.
​
(params: ListAppUsersParams) => Promise<ListAppUsersResponse>
List the application’s users. Public.Parameters:
  • params: ListAppUsersParams
    • clientId: string — the application’s public client ID (required)
    • pageSize?: number — items per page, 1 to 1000 (default 20); a larger value is rejected
    • pageToken?: string — cursor pagination. Omitted or "" starts the walk; otherwise pass the previous response’s nextPageToken. There is no page: the SDK rejects one with a ValidationError before sending, and a raw REST request carrying it gets 400. The filters must match the request that minted the token
    • isActive?: boolean — filter by active status
    • accountType?: string — filter by account type: master or sub
    • address?: string — filter by wallet address (partial match, case-insensitive)
Returns: ListAppUsersResponse:
  • users: AppUser[] — matching users
  • total: number — users matching the filter, bounded by the server count ceiling
  • pageSize: number — items per page
  • totalPages: number — pages at this pageSize, bounded by the same ceiling
  • nextPageToken: string — cursor for the next page, "" once the walk is exhausted. Each page over-fetches one row, so an empty token is definitive: follow a non-empty token, stop on an empty one
  • totalCapped: boolean — true when more than the server ceiling matched, so total / totalPages are a lower bound
Ordered by user id ascending, not newest-first: created_at is nullable on this table, so it cannot be a total cursor key, and excluding the rows without one would hide users from the listing an application reconciles against.
​
(params: ListAppMovementsParams) => Promise<ListAppMovementsResponse>
List ledger movements (deposits, withdrawals, trades, fees, etc.) for the application’s users. Public.Parameters:
  • params: ListAppMovementsParams
    • clientId: string — the application’s public client ID (required)
    • pageSize?: number — items per page, 1 to 1000 (default 20); a larger value is rejected
    • pageToken?: string — cursor pagination. Omitted or "" starts the walk; otherwise pass the previous response’s nextPageToken. There is no page: the SDK rejects one with a ValidationError before sending, and a raw REST request carrying it gets 400. The filters must match the request that minted the token
    • userId?: string — filter by user UUID
    • transactionType?: string — filter by transaction type (e.g. DEPOSIT, WITHDRAWAL, TRADE, FEE, FUNDING, LIQUIDATION, INTEREST, REWARD)
    • entryType?: string — filter by entry type (e.g. CREDIT, DEBIT, LOCK, UNLOCK, FEE)
    • assetId?: string — filter by asset UUID
Returns: ListAppMovementsResponse:
  • movements: AppMovement[] — matching movements
  • pageSize: number — items per page
  • nextPageToken: string — cursor for the next page, "" once the walk is exhausted. Each page over-fetches one row, so an empty token is definitive: follow a non-empty token, stop on an empty one
No item count: the underlying ledger is too large to count behind a filter. A movement with no recorded timestamp is not listed — the column is nullable, and a NULL has no position in the cursor’s sort key.Deposits and withdrawals that go straight into or out of a margin account are listed too: transactionType DEPOSIT or WITHDRAWAL, entryType CREDIT or DEBIT, referenceType margin_account_deposit or margin_account_withdrawal, and referenceId the margin account. They carry no balanceBefore, balanceAfter, lockedBefore or lockedAfter, and balanceId falls back to the margin account’s ID when it has no bound collateral balance. The filters and pageToken cover them. Margin funding from before v1.0.87 is not listed, and funding payments are not part of this listing.
​
(params: ListAppBalancesParams) => Promise<ListAppBalancesResponse>
List user wallet balances held within the application. Public.Funds held in a margin account are not included, so a user funded through margin can show zero here. Read those users from GET /api/v1/applications/margin-accounts with listApplicationMarginAccounts.Parameters:
  • params: ListAppBalancesParams
    • clientId: string — the application’s public client ID (required)
    • pageSize?: number — items per page, 1 to 1000 (default 20); a larger value is rejected
    • pageToken?: string — cursor pagination. Omitted or "" starts the walk; otherwise pass the previous response’s nextPageToken. There is no page: the SDK rejects one with a ValidationError before sending, and a raw REST request carrying it gets 400. The filters must match the request that minted the token
    • userId?: string — filter by user UUID
    • assetId?: string — filter by asset UUID
Returns: ListAppBalancesResponse:
  • balances: AppBalance[] — matching balances. lastSyncAt, lastSyncBlock and onChainBalance are deprecated: they are not kept up to date and must not be used, and they are not a sync or health signal
  • total: number — balances matching the filter, bounded by the server count ceiling
  • pageSize: number — items per page
  • totalPages: number — pages at this pageSize, bounded by the same ceiling
  • nextPageToken: string — cursor for the next page, "" once the walk is exhausted. Each page over-fetches one row, so an empty token is definitive: follow a non-empty token, stop on an empty one
  • totalCapped: boolean — true when more than the server ceiling matched, so total / totalPages are a lower bound
Ordered by balance id ascending. Not by updatedAt, which the removed page-number mode sorted on: that column changes on every balance movement, so a walk over it could repeat or skip rows with no concurrent insert at all.
​
(params: ListAppMarginAccountsParams) => Promise<ListAppMarginAccountsResponse>
List the application’s margin accounts, one row per margin account with sub-accounts beside their parent. Public.Margin collateral is not a wallet balance, so an application that funds its users through margin reads it here, not from listApplicationBalances.Parameters:
  • params: ListAppMarginAccountsParams
    • clientId: string — the application’s public client ID (required)
    • address?: string — keep only this wallet’s margin accounts. A wallet with no margin account in the application returns an empty page
    • pageSize?: number — items per page, 1 to 1000 (default 20); a larger value is rejected
    • pageToken?: string — cursor pagination. Omitted or "" starts the walk; otherwise pass the previous response’s nextPageToken. The filters must match the request that minted the token
Returns: ListAppMarginAccountsResponse:
  • marginAccounts: AppMarginAccount[] — marginAccountId, userId, address, subaccountKey (default is the parent), marginAccountState (ACTIVE or CLOSED), collateral, equity, freeCollateral, withdrawableCollateral, updatedAt
  • total: number — margin accounts matching the filter, bounded by the server count ceiling
  • pageSize: number — items per page
  • totalPages: number — pages at this pageSize, bounded by the same ceiling
  • nextPageToken: string — cursor for the next page, "" once the walk is exhausted
  • totalCapped: boolean — true when more than the server ceiling matched, so total / totalPages are a lower bound
Ordered by margin account id ascending. The figures are a persisted baseline repriced at the latest risk marks, so they can briefly lag the matching engine. A risk bucket is not a row: its collateral and held realized PnL are already in the account’s figures. Reserved sub-accounts are not listed, so the rows need not add up to all of a wallet’s margin collateral.
​
(params: GetAppStatsParams) => Promise<GetAppStatsResponse>
Fetch aggregate volume and fee metrics for an application. Public.Stats are scoped to trades where this application’s users were the taker.Parameters:
  • params: GetAppStatsParams
    • clientId: string — the application’s public client ID (required)
    • since?: string — ISO 8601 datetime, e.g. "2026-01-01T00:00:00Z". Omit for all-time
The read has a 3-second budget: one that cannot finish in time fails with 503. All-time stats for a large application can hit it; pass since to narrow the window.Returns: GetAppStatsResponse:
  • volume: string — total quote volume (normalized, human-readable)
  • makerFee: string — total maker fees collected
  • takerFee: string — total taker fees collected
  • applicationTakerFee: string — builder fees your application charged its users as takers (taker side only)
  • tradeCount: number — total number of trades
  • applicationMakerFee?: string — maker add-ons your application charged its users as makers
  • builderFeeTotal?: string — your total builder-fee revenue: applicationTakerFee plus applicationMakerFee
Example: