Skip to content

Command Status API

Looks up a previously submitted command by ID, across command-log and canonical-outcome storage depending on processing mode.

{
"commandId": "...",
"clientId": "...",
"route": "/api/v1/orders/submit",
"idempotencyKey": "...",
"status": "ACCEPTED | IN_FLIGHT | COMPLETED | REJECTED | FAILED",
"internalStatus": "RECEIVED | PROCESSING | COMPLETED | FAILED",
"processingMode": "sync-result | captured-ack | stream-ack | accepted-async",
"responseStatus": 200,
"responsePayloadJson": "...",
"lastError": "",
"canonicalMaterialized": true,
"engineResultStatus": "accepted | rejected",
"resultStatus": "accepted | rejected",
"batchId": "...",
"shardId": "...",
"partition": 0,
"commandStream": "...",
"eventStream": "...",
"streamSequence": 0,
"deliveredCount": 0,
"commandType": "SubmitOrder",
"payloadHash": "...",
"instrumentId": "...",
"orderId": "...",
"rejectCode": "",
"resultPayloadJson": "..."
}

status is provider-neutral. ACCEPTED means the command is durably accepted but not yet draining; IN_FLIGHT means worker/engine processing has started; COMPLETED means a canonical accepted outcome exists; REJECTED means a canonical business reject exists; FAILED means a terminal failure outcome exists. Legacy queue/provider state remains diagnostic as internalStatus.

canonicalMaterialized is true once the command’s outcome has been durably materialized into compact canonical Postgres storage from the venue event batch (stream-ack mode) rather than only captured at intake.

When a mutation returns 202 Accepted in stream-ack/accepted-async mode, the immediate response is a smaller pointer, not the full status:

{
"commandId": "...",
"status": "ACCEPTED",
"processingMode": "stream-ack",
"statusUrl": "/api/v1/commands/{commandId}"
}

Poll statusUrl to get the full status view above once processing completes.

  • API Overview — processing modes and the durable-acceptance contract
  • Orders API — the mutation routes this status lookup tracks