Result Modes

Order Entry exposes the venue hotpath directly. Every submission lets the client choose how far the engine must get before the HTTP or FIX response returns. This is the single source of truth for the three result modes (ack, durable, full), the acknowledgement boundaries they map to, and the headers that select and report them.

Result mode is orthogonal to payload verbosity. Do not conflate "how much detail comes back" with "how far the request got." The result mode selects the acknowledgement boundary; the response payload then reflects whatever state was reached at that boundary.

For connectivity, base URLs, credentials, signing, and the submission lanes themselves, see Order Entry Lanes and Authentication. This page only covers result modes.

The three modes

Mode	Acknowledgement boundary	Meaning	Use
ack	Sequencer accepted the request boundary.	The request was admitted to sequencing. Lowest response overhead.	High-rate quote refresh where the private execution stream is the primary reconciliation path.
durable	WAL / durable LSN boundary reached.	The request is persisted to the write-ahead log.	Slower control flows where persistence acknowledgement matters more than response latency.
full	Engine-applied result returned from the hotpath.	The terminal engine result is included when available.	IOC/FOK, cancel, replace, and any flow where the client needs the terminal result immediately.

Rules of thumb:

• Use ack for high-rate quote refreshes that reconcile from the stream.
• Use full for IOC/FOK, cancel, and replace.
• Use durable only when persistence acknowledgement is more important than response latency.

Selecting a result mode

Result mode is selected with the x-bsl-result-mode HTTP header or, on JSON batches, the body resultMode field. The two select the same axis; the header is authoritative for compact/byte submissions that carry no JSON envelope.

POST /api/v1/order-entry/orders
Content-Type: application/json
x-bsl-result-mode: full
Idempotency-Key: strategy-42-batch-9001

{
  "resultMode": "full",
  "actions": [
    { "payload": {}, "signature": "0x..." }
  ]
}

The SDK responseMode / response_mode option maps directly to this header:

await client.orderEntry.submitActions([signedAction], {
  idempotencyKey: "batch-9001",
  responseMode: "full",
});

client.order_entry.submit_actions(
    [signed_action],
    idempotency_key="batch-9001",
    response_mode="full",
)

use senticore_sdk::OrderEntryResultMode;

client
    .order_entry
    .submit_actions(
        vec![signed_action],
        OrderEntrySubmitOptions::default()
            .idempotency_key("batch-9001")
            .response_mode(OrderEntryResultMode::Full),
    )
    .await?;

Legacy header names

The result-mode and ack-boundary headers have legacy aliases that remain accepted for compatibility. New clients should use the x-bsl-* names.

Axis	Preferred header	Legacy aliases
Result mode	x-bsl-result-mode	x-bsl-response-mode, x-mm-ack-mode, x-mm-response-mode, x-mm-response-detail
Ack boundary	x-bsl-ack-*	x-mm-ack-*

Acknowledgement boundaries

Each result mode maps to a point in the hotpath. The x-bsl-ack-* response headers (and the timing object on JSON responses) report which boundaries the request actually reached: accepted, WAL, applied, primary durable, or cluster durable. A full request that the engine has not yet applied returns the furthest boundary it did reach, so the client can tell admission from execution.

The durable truth for all modes is the sequencer/execution stream. HTTP and FIX responses are acknowledgements at the requested boundary, not a substitute for stream reconciliation:

• A non-full HTTP 200 is not a terminal order state. ack means the request boundary was accepted; fills, cancels, and rejects still come from the execution stream or gap-fill.
• FIX order entry returns a synchronous PendingNew ExecutionReport (35=8, 150=A, 39=A), but final fills, cancels, and rejects arrive asynchronously on drop-copy.

See Order Entry Lanes for the per-lane transport details.

full results

full responses include actionResults when the request reaches the engine. Each result carries the client order id, order id, status, filled quantity, leaves quantity, average price, fee, reject code, market, shard, seq, and engine timestamps when available.

For cancel/replace, reconcile full from the engine result rather than from request acceptance:

Status	Client action
filled	Position and exposure changed immediately.
partially_filled	Continue quoting with updated leaves quantity.
resting	New order is live on the book.
canceled	Cancel side completed.
rejected	Inspect rejectCode; do not assume the old order is gone unless the result says so.

Response contract

Every JSON response carries a contract object reporting the requested and resolved result mode, the stream-truth source, replay paths, and timing:

{
  "bsl": {
    "contract": "BSL_ORDER_ENTRY_V1",
    "contractVersion": 1,
    "surface": "orderEntry",
    "transport": "json",
    "requestedResultMode": "full",
    "resultMode": "full",
    "streamTruth": "engine_execution_ring",
    "privateWsPath": "/api/v1/ws/bsl/{account}",
    "executionReplayPath": "/api/v1/bsl/accounts/{account}/executions?fromSeq={seq}",
    "rejectCode": null,
    "timing": {
      "gatewayReceivedTs": 1781715570085,
      "authDoneTs": 1781715570085,
      "riskDoneTs": 1781715570085,
      "sequencedTs": 1781715570085,
      "engineAppliedTs": 1781715570086,
      "durableTs": null,
      "responseSentTs": 1781715570086,
      "durationsUs": {
        "total": 1072,
        "auth": 3,
        "routing": 12,
        "risk": 0,
        "enqueue": 0,
        "ackResolution": 0,
        "responseEmit": 58
      }
    }
  }
}

requestedResultMode echoes what the client asked for; resultMode reports what the response actually resolved to. Compact/byte responses expose the same contract through x-bsl-* headers.

Timing fields

Field	Meaning
gatewayReceivedTs	Server ingress timestamp.
authDoneTs	Auth and credential gate completed.
riskDoneTs	Risk or credit approval completed when applicable.
sequencedTs	Request entered sequencing.
engineAppliedTs	Engine terminal event timestamp when available.
durableTs	Durable acknowledgement timestamp when requested and reached.
responseSentTs	Response emission timestamp.

The durationsUs object carries microsecond breakdowns for auth, routing, risk, enqueue, ack resolution, response emission, and total server time, so clients can locate latency instead of guessing.

Legacy route names

"MM", "BSL", and "binary" are legacy aliases for Order Entry. The result-mode contract is identical across all of them, and the x-bsl-result-mode / resultMode selectors apply unchanged whether you submit to the canonical POST /api/v1/order-entry/orders (and .../orders/compact) endpoints or to a live alias route. The legacy x-mm-ack-mode header is the only mode selector spelled differently; treat it as equivalent to x-bsl-result-mode.

Related pages

• Order Entry Lanes
• Authentication
• Error Model