BSL Execution Streams
The BSL private stream is the primary truth for institutional clients. Database reads are for backfill and recovery, not the main order lifecycle.
WebSocket
GET /api/v1/ws/bsl/{account}?token=<ws-session-token>
The stream is account scoped and emits execution events from the engine result
ring. Events are monotonic by seq; clients must persist the latest processed
sequence before acknowledging work inside their own system.
Each execution event includes the fields needed for deterministic reconciliation:
| Field | Purpose |
|---|---|
seq | Monotonic venue sequence. |
clientOrderId | Strategy id supplied in the signed payload. |
orderId | Venue order id. |
status | Terminal or current order status. |
filledQty | Filled quantity for this result. |
leavesQty | Remaining live quantity. |
fillId | Fill identifier when a trade event exists. |
rejectCode | Stable machine code for rejects. |
market | Market id. |
shard | Market shard id. |
engineTsMs | Engine timestamp. |
serverTsMs | Server event timestamp. |
Gap Fill
GET /api/v1/bsl/accounts/{account}/executions?fromSeq=12345
Authorization: Bearer <short-lived-token>
Use gap-fill after reconnect or when a client detects a sequence jump. The response is the same private execution stream model returned over WebSocket.
Snapshot and Delta
Clients should run this startup sequence:
- Fetch open orders snapshot.
- Open BSL private WebSocket.
- Gap-fill from the snapshot sequence to the stream sequence.
- Apply stream deltas monotonically.
Do not use periodic private reads as the normal lifecycle source for high-rate strategies. They add read-plane latency and make cancel/replace behavior feel worse than the engine actually is.
Token Model
Browser sessions and API-agent sessions get short-lived private read tokens from:
POST /api/v1/ws/token
The token is accepted by BSL private read endpoints even when the HTTP platform plane and trading plane do not share an in-memory registry. Revocation and credential checks still consult persistent control-plane state.