BSL Order Entry

BSL order entry exposes the hotpath result contract directly. Use it when a client needs deterministic, low-latency answers for place, cancel, replace, and quote-refresh flows.

JSON Batch

POST /api/v1/bsl/orders/batch
Content-Type: application/json
X-BSL-Result-Mode: full
Idempotency-Key: strategy-42-batch-9001

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

The actions array contains signed actions. clientOrderId must be inside the signed action payload when the client needs deterministic reconciliation by client id.

For base submit, the account signature is the primary authority. A provisioned X-Senticore-Order-Entry-Key may be supplied by operations for dedicated lanes or elevated limits, but it is not a public shared secret and is not required for ordinary beta signed-submit access when the route policy allows signed submit without a lane key.

For quote engines, generate clientOrderId from the strategy's own order key and persist it before sending the batch. Use Idempotency-Key for HTTP retry deduplication; use clientOrderId for strategy reconciliation after the engine has accepted or rejected the order.

Compact Batch

POST /api/v1/bsl/orders/compact
Content-Type: application/x-senticore-order-entry-batch
X-BSL-Result-Mode: ack

The body is the compact order-entry batch payload used by low-latency clients. The response carries BSL metadata in x-bsl-* headers and keeps the body shape compatible with existing compact clients.

If operations assigns a dedicated lane key, include it as X-Senticore-Order-Entry-Key. The legacy X-MM-Key header is accepted only as a compatibility alias and should not be used by new clients.

The private-beta alias POST /api/order-entry/binary accepts the same payload. Prefer the BSL route for new integrations; keep the alias only when a released SDK or edge profile still expects it.

Cancel and Replace

POST /api/v1/bsl/orders/replace
Content-Type: application/json
X-BSL-Result-Mode: full

Replace is modeled as one BSL result boundary. Clients should not infer success from request acceptance alone. In full mode the response must be reconciled from the engine result:

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 old order is gone unless the result says so.

Cancel by clientOrderId, mass-cancel per session, and cancel-on-disconnect should use the same BSL session and private stream for reconciliation.

For high-frequency quoting, do not treat HTTP 200 on a non-full request as a terminal order state. ack means the request boundary was accepted; the execution stream or gap-fill is still the source for fills, cancels, and rejects.

Timing Fields

Every BSL response includes timing fields so clients can locate latency instead of guessing:

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.

Client Rules

• 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.
• Treat Idempotency-Key as the retry dedup key.
• Treat clientOrderId as the strategy correlation id.
• On SHARD_BUSY or QUEUE_LIMIT, back off or reroute quoting for that market.