Real-time Fills

Your fills push on the private account:fills#<accountId> channel as kind: "fill" payloads. Both parties receive one when a trade crosses, and again on every settlement transition, so your local state converges even if you miss a step. Connection and auth are covered in Realtime Socket; the kind: "order" payloads sharing this channel are in order updates.

{
  "kind": "fill",
  "executionId": "2cd3835c-cc3b-44df-a301-03f71bdb47f8",
  "version": 1,
  "status": "SETTLING",
  "side": "SELL",
  "takerSide": "SELL",
  "orderId": "c3c022bd-21e5-4a9f-b0ef-5e4a7280ef3b",
  "marketId": "2406c582-64f0-4192-a7f2-f2cb70e5d652",
  "assetConfigurationId": "315bc6db-3f16-49ec-b649-8be3b8753fb7",
  "quantity": 1,
  "executionPriceCents": 878,
  "grossAmountCents": 878,
  "executedAt": "2026-09-12T18:04:37.551Z",
  "realizedPnlCents": null,
  "unitCostBasisCents": null,
  "acquiredAt": null
}

Field	Description
executionId	The fill — matches id on getOrderExecution
version	Settlement ordinal: PENDING 0, SETTLING 1, SETTLED/FAILED 2, REVERSED 3. Keep the highest per executionId
status	The OrderExecutionStatus
side	Your side of the trade — BUY if you bought, SELL if you sold
takerSide	Which side crossed the book
orderId	Your own submission id. The counterparty's is never sent
realizedPnlCents / unitCostBasisCents / acquiredAt	Seller economics, populated from the first push after processing. Null means not yet known, never zero

Pushes can arrive out of order; version is the tiebreaker, not arrival time. Reconcile by reading listOrderExecutions after subscribing and after any reconnect.