Querying Submissions

getOrderSubmission fetches one submission; listOrderSubmissions pages your submissions with filters and aggregate totals.

Fetching one

Look up by our id or by yours — submissionId or externalReferenceId. Passing neither returns INPUT_REQUIRED; an unknown id returns ORDER_SUBMISSION_NOT_FOUND.

query {
  getOrderSubmission(input: {
    submissionId: "8707caa9-ec78-4b46-a787-b97c27a6042e"
    includeProductData: true
    includeBookPosition: true
  }) {
    submission {
      id status qty allInPrice isTopOfBook
      assetConfigurations { id name }
      assets { id name }
      keys { id name }
    }
    filledQuantity
    remainingQuantity
    settledQuantity
    error { message code }
  }
}

{
  "getOrderSubmission": {
    "submission": {
      "id": "8707caa9-ec78-4b46-a787-b97c27a6042e",
      "status": "RESTING",
      "qty": 5,
      "allInPrice": 1557,
      "isTopOfBook": true,
      "assetConfigurations": [{ "id": "315bc6db-3f16-49ec-b649-8be3b8753fb7", "name": "Destined Rivals Booster Pack" }],
      "assets": [{ "id": "479d8355-02a5-479d-b3e6-0b77e6ba892f", "name": "SV10: Destined Rivals" }],
      "keys": [{ "id": "4a9a2cca-c05f-5474-9979-428dc6f41107", "name": "MINT" }]
    },
    "filledQuantity": 0,
    "remainingQuantity": 5,
    "settledQuantity": 0,
    "error": null
  }
}

Filled versus settled

The payload carries two cumulative counters, and the distinction is the same one the status lifecycle makes:

Counter	Counts	Use it for
filledQuantity	Units matched on the book	Working-size math: remainingQuantity is what still rests
settledQuantity	Units actually delivered (settled)	Telling someone what they now own

settledQuantity lags filledQuantity while settlement is in flight, and stays behind it permanently when a fill fails — settledQuantity < filledQuantity on a terminal submission is the signal that some of it never completed. Reversed fills are excluded from both; failed fills still count as filled while settlement can retry them.

Listing

Filters

All filters compose (AND). Everything is scoped to your account.

Filter	Type	Matches
status	OrderSubmissionStatus	One lifecycle status
statuses	[OrderSubmissionStatus!]	Any of several — e.g. everything still working the book, [RESTING, PARTIALLY_FILLED]. Pass this or status, not both
direction	OrderSubmissionDirection	Only buys or only sells
marketIds	[UUID!]	Submissions targeting these markets
assetIds	[UUID!]	Submissions targeting these assets
assetConfigurationIds	[UUID!]	Submissions targeting these configurations
assetTypeIds	[UUID!]	Submissions whose products belong to these asset classes
biddingStrategyIds	[UUID!]	The managed identity submissions of these strategies
externalIdentifiers	JSON	Submissions targeting the configurations these platform ids resolve to — see Targeting by external identifiers
createdAfter / createdBefore	DateTime	Creation-time window

externalIdentifiers matches by resolved configuration, so a submission created with one platform's id is findable by another's. Unresolvable ids return an empty page; an unknown platform errors.

Include flags

Reads are lean by default; each flag has a cost, so ask only where the data is rendered.

Flag	Adds	Cost
includeProductData	Catalog rows: asset configurations, parent assets, keys	Join per page
includeChildBidOrAsk	The resting order each submission materialized into (conditionalBids on a BUY, conditionalAsks on a SELL), with the clean book price alongside the fee-inclusive all-in and the venues it rests in. List queries only	One query per side
includeBookPosition	isTopOfBook per resting submission	A live book read per distinct instrument the page spans
includeTotals	Aggregates over the full filtered set	One extra aggregate query

Totals

query {
  listOrderSubmissions(input: {
    status: RESTING
    direction: BUY
    includeTotals: true
    pagination: { first: 1 }
  }) {
    submissions { id qty allInPrice }
    pageInfo { hasNextPage endCursor }
    totals { totalCount openValueCents }
  }
}

{
  "submissions": [{ "id": "8707caa9-ec78-4b46-a787-b97c27a6042e", "qty": 5, "allInPrice": 1557 }],
  "pageInfo": { "hasNextPage": true, "endCursor": "eyJ0cyI6ICIyMDI2LTA4LTA4..." },
  "totals": { "totalCount": 2, "openValueCents": "8485" }
}

Totals cover everything the filters match, independent of the page. Two things to note:

• openValueCents is a BigInt, serialized as a string — parse it, don't treat it as a number.
• It only sums RESTING rows (allInPrice × qty). With a terminal status filter it reads zero while totalCount still counts the matches: { "totalCount": 156, "openValueCents": "0" } is a correct answer for status: CANCELLED.

Pagination

Cursor-based, newest first. pagination: { first, after }, default page size twenty. Walk pages by passing pageInfo.endCursor back as after until hasNextPage is false:

query {
  listOrderSubmissions(input: {
    status: RESTING
    pagination: { first: 1, after: "eyJ0cyI6ICIyMDI2LTA4LTA4..." }
  }) {
    submissions { id qty allInPrice createdAt }
    pageInfo { hasNextPage endCursor }
  }
}

Cursors are keyset-based (creation time plus id), so a page walk stays stable while new submissions are created — new arrivals land before your first page, never inside the pages you've already read. Treat the cursor as opaque.