☰

Developers › API reference

Orders API

Enter, amend, approve, release, cancel and allocate (simulated) orders; fills; blotter views.

Objects

  • Order: one security and side, split across one or more accounts (allocations; a block when several). It carries its state, compliance state, approval requirement, algorithm and slices, simulated fills and its history. hidden_allocations counts allocations on accounts you may not see (never shown).
  • Fill: a simulated execution of a slice, with its price, the arrival price and slippage.
  • Blotter view: a saved layout of the trade blotter.

Everything is simulated: "simulated": true. Nothing reaches a broker.

Order states

proposed → pending_compliance → compliance_hold ─(override)─┐
                              → rejected                    │
                              → pending_approval → approved → working → partially_filled → filled
                                                 → rejected   (cancel at any open state → cancelled)
StateNext call
compliance_holdPOST /orders/{id}/override with a reason (Compliance decides above the threshold: POST /overrides/{id}/decision)
pending_approvalPOST /orders/{id}/approve or /reject, by someone with approve on every account who did not enter it
approvedPOST /orders/{id}/release with an algorithm and slices
working, partially_filledwait, POST /orders/{id}/release (mode all runs the remaining slices), /rework, /amend or /cancel
filledOperations: POST /orders/{id}/allocate

The compliance check

POST /orders runs the pre-trade check before answering. The answer's result has the compliance results (rule, outcome, measured, limit), who must still approve, and whether an override is needed. A hard block creates the order in state rejected (201), with the failed checks in result.compliance. Amendments and releases re-check: if they would now break a rule they answer 422 compliance_blocked with the checks in the problem's checks, and nothing changes. Every executed slice is checked against the in-trade rules.

Typical sequence

  1. POST /orders (Idempotency-Key) → pending_approval.
  2. Another person: POST /orders/{id}/approve.
  3. A trader: POST /orders/{id}/release {"algo":"vwap","slices":4} → working.
  4. GET /orders/{id}/fills, or listen to the webhooks order.updated and fill.created.

Amendments need If-Match with the order's ETag (412 when it changed meanwhile).

Endpoints

CallWhat it doesScope
GET/ordersOrders on the accounts you can seeorders:read
GET/orders/{id}One order with allocations, compliance and historyorders:read
POST/ordersEnter an order: checked by compliance and routed by the workflow rules like any order (paper trading)orders:write
POST/orders/{id}/amendAmend quantity or limit (compliance re-checked; If-Match)orders:write
POST/orders/{id}/cancelCancel the unfilled partorders:write
POST/orders/{id}/releaseRelease an approved order to the simulator (compliance re-checked)orders:write
POST/orders/{id}/reworkRe-plan a working order's unfilled shares with another algoorders:write
POST/orders/{id}/approveApprove (four eyes: never the person who entered it)orders:approve
POST/orders/{id}/rejectRejectorders:approve
POST/orders/{id}/overrideOverride a soft compliance warning with a written reasonorders:write
POST/orders/{id}/allocateConfirm the allocation of executions (Operations)orders:write
GET/orders/{id}/fillsSimulated fills of an orderorders:read
GET/executionsSimulated fills on the accounts you can seeorders:read
GET/blotter/viewsSaved blotter views (yours and the firm's)orders:read
POST/blotter/viewsSave a blotter view (validated against the field registry)orders:write
PUT/blotter/views/{id}Replace a blotter vieworders:write
DELETE/blotter/views/{id}Delete a blotter vieworders:write