Order Entry
Order Entry is Senticore's professional, latency-sensitive order-entry contract. It is the surface for institutional quoting, cancel/replace, execution replay, and session controls.
Order Entry is not a separate matching engine. Orders pass through the same auth, risk, sequencing, WAL, matching, event ring, recovery, and settlement model as the rest of the venue. The difference is that the contract exposes that hotpath truth directly — explicit result modes, stable reject codes, hotpath order results, private execution streams, gap-fill, and timing breakdowns — instead of hiding it behind read-plane polling.
For connectivity, credentials, and request signing, see
Authentication and
Action Signing. All hosts, paths, and ports are
covered in Getting Started: one host per
environment, REST under {host}/api/v1/....
The two HTTP lanes
Order Entry over HTTP exposes two lanes. A third lane, FIX, is documented separately. All lanes submit into the same sequencer and engine; they differ only in client protocol, operational setup, and response contract.
| Lane | Transport | Use it when | Payload |
|---|---|---|---|
| JSON | HTTPS JSON | You want the easiest, debuggable integration path: app backends, bots, low-volume strategy services, IOC/FOK takers. | JSON signed-action batch with explicit result mode. |
| Compact/binary | HTTPS byte body | You want lower-overhead batch submission for quote engines and market makers without standing up a FIX session. | UTF-8 JSON bytes today; the server also accepts the internal cold binary encoding on the same endpoint. |
Compact/binary is not FIX. It is an HTTPS POST with a byte body, not a TCP/TLS session with CompIDs, sequence numbers, Logon, and Heartbeat. For the full three-way comparison including FIX, see Order Entry Lanes.
Canonical endpoints
| Endpoint | Lane | Purpose |
|---|---|---|
POST /api/v1/order-entry/orders | JSON | Signed-action batch with explicit result mode. |
POST /api/v1/order-entry/orders/compact | Compact/binary | Compact byte batch for latency-sensitive clients. |
Each actions[] item is the same signed action envelope used by the normal
sequencer ingress — there is no separate matching, risk, lifecycle, or
settlement semantics for either lane. The byte lane still carries signed
actions; it does not replace action signing.
The compact lane expects:
POST /api/v1/order-entry/orders/compact
Content-Type: application/x-senticore-order-entry-batch
Accept: application/x-senticore-order-entry-batch-response, application/json
Idempotency-Key: <stable-batch-key>
Result modes and truth
Both lanes select a result boundary with the resultMode JSON field or the
x-bsl-result-mode header. Compact byte responses expose the same contract
through x-bsl-* headers.
| Mode | Meaning | Use |
|---|---|---|
ack | Sequencer accepted the request boundary. | High-rate quote refreshes that reconcile from the execution stream. |
durable | WAL/durable LSN boundary reached. | Slower control flows where persistence acknowledgement matters. |
full | Engine-applied result returned from the hotpath. | IOC/FOK, cancel, replace, and any flow that needs the terminal result immediately. |
For all lanes, the durable truth is the sequencer/execution stream. An HTTP
response is an acknowledgement at the requested boundary — a 200 in a
non-full mode does not mean an order is filled or resting. Use full to
get the engine-applied result inline, or reconcile through the private execution
stream and gap-fill. Treat fast rejects (SHARD_BUSY, QUEUE_LIMIT,
RISK_CREDIT_LIMIT, KILL_SWITCH, MARKET_HALTED) as first-class strategy
events: a quick reject is healthier than a quote aging silently in an overloaded
queue.
Legacy route names
MM, BSL, and binary are legacy aliases for Order Entry. They are not
separate products and remain only as live compatibility routes; new integrations
should use the canonical order-entry names above.
| Legacy route | Canonical equivalent |
|---|---|
POST /api/v1/bsl/orders/batch | POST /api/v1/order-entry/orders |
POST /api/v1/bsl/orders/compact | POST /api/v1/order-entry/orders/compact |
POST /api/v1/mm/orders/batch | POST /api/v1/order-entry/orders |
POST /api/v1/mm/orders/batch.bin | POST /api/v1/order-entry/orders/compact |
POST /api/order-entry/binary | POST /api/v1/order-entry/orders/compact |
The compatibility media types application/x-senticore-mm-batch,
application/x-senticore-binary, and application/octet-stream are still
accepted on the compact endpoint, as is the legacy X-MM-Key header alias.
Next
- Orders — payload shape, signing, client order ids, and idempotency.
- Result Modes — response contract and reject codes in detail.
- Execution Streams — private streams, receipts, and gap-fill.
- Operations — limits, sessions, cancel-on-disconnect, and go-live posture.
- Authentication and Action Signing — credentials and signing.