Skip to main content
This is the map of the Orders module. It explains, in plain English, what kinds of orders you can place, how the platform decides which kind you meant, what happens to an order after you submit it, and how to follow its status in real time. The following pages drill into each individual order type with copy-paste request and WebSocket examples.
One endpoint places every order. You always POST /v1/orders. You never pick the order type in the URL — the platform infers it from the fields you send (see How the order type is decided). This is why the per-type pages all hit the same endpoint with a different body.

​
The two halves of trading on Aries

Placing an order is a request/response action over REST. But an order is not “done” when the REST call returns — it then lives a life on the exchange (working, partially filling, filling, getting cancelled, etc.). You watch that life over a WebSocket. So a robust trading app does both, in this order:
  1. Subscribe first to the Account Updates WebSocket — authenticate and subscribe to the account topic for your accountId. You get a snapshot of current orders, positions, and balance right away, and won’t miss any update that fires the moment you place.
  2. Then place the order over POST /v1/orders. The response is an acknowledgement, not a fill — it confirms the order was accepted and returns the clOrdId you use to track, cancel, or replace it.
  3. Watch it resolve on the WebSocket. State changes arrive as account.order events — NEW → PARTIALLY_FILLED → FILLED, or terminal REJECTED/CANCELED/EXPIRED. These come only over the socket; REST never sends a second response.
In short: REST acts on an order; the WebSocket tells you what happened to it.

​
Order types you can place

Aries supports four order types (how the order is priced and triggered) across three asset shapes (equity, single option, multi-leg option).

​
By pricing / trigger

TypeWhat it doesRequired price fieldsGuide
MarketFills immediately at the best available price. No price guarantee.noneMarket order
LimitFills only at your price or better. Price guarantee, no fill guarantee.priceLimit order
StopDormant until the stop price is touched, then becomes a market order.stopPriceStop order
Stop-LimitDormant until the stop price is touched, then becomes a limit order.stopPrice + priceStop-limit order

​
By instrument

ShapeHow you express itGuide
EquityNo legs array — just a symbol.All four type pages above
Single-leg optionExactly 1 entry in legs.Single-leg option
Multi-leg option2–4 entries in legs (verticals, calendars, ratio spreads, etc.).Multi-leg option
Any of the four pricing types can apply to equities or single options. Multi-leg option orders in practice use Market or Limit (a limit price on a spread is the net debit/credit across all legs).

​
How the order type is decided

You never send a field called “this is an equity order.” Instead:
  • No legs → equity order. The top-level symbol is the stock/ETF.
  • 1 leg → single-leg option order.
  • 2–4 legs → multi-leg option order.
The pricing type comes from the type field (MARKET, LIMIT, STOP, STOP_LIMIT), and the price fields you must include depend on it. Each per-type page shows the exact body.
Time-in-force is restricted for options. Equity orders accept DAY, GTC, IOC, and FOK. Orders that carry legs (any option order) only accept DAY or GTC — sending IOC/FOK on an option order is rejected.

​
Anatomy of a place-order request

Every order — equity or option — shares this core. The per-type pages only change which optional fields are present.
FieldRequiredDescription
tradingAccountIdyesThe trading account placing the order.
symbolyesThe instrument symbol (underlying symbol for options).
sideyesBUY, SELL, SELL_SHORT, or BUY_TO_COVER.
typeyesMARKET, LIMIT, STOP, or STOP_LIMIT.
qtyyesQuantity as a decimal string (e.g. "100").
timeInForceyesDAY, GTC, IOC, FOK (options: DAY/GTC only).
priceconditionalLimit price. Required for LIMIT and STOP_LIMIT.
stopPriceconditionalTrigger price. Required for STOP and STOP_LIMIT.
legsconditional1–4 option legs. Presence makes it an option order.
clientIdnoYour own correlation identifier, echoed back.
currencyno3-letter currency code; defaults to USD.
exDestinationnoRouting hint (MNGD). Managed routing is applied automatically; you normally omit this.
All monetary and quantity values are sent and returned as JSON strings, not numbers, to preserve decimal precision. Send "150.50", not 150.5.

​
What you get back

A successful POST /v1/orders returns an acknowledgement, not a fill. The key fields:
FieldMeaning
successWhether the order was accepted.
clOrdIdThe client order ID. Track the order by this and use it as origClOrdId to cancel or replace.
statusInitial status — usually PENDING_NEW or NEW.
cumQty / leavesQtyFilled vs. remaining quantity (usually 0 / full at acknowledgement).
avgPriceAverage fill price (fills as they happen).
ordRejReasonPopulated only if the order was rejected.
transactTimeServer timestamp.
Everything after this — the actual fills — comes over the WebSocket.

​
The order lifecycle

Orders move through a well-defined set of states. You’ll see these as the ordStatus field on account.order WebSocket events.
StatusMeaning
PENDING_NEWSubmitted, not yet accepted by the exchange.
NEWLive and working on the book.
PARTIALLY_FILLEDSome quantity executed; rest still working.
FILLEDFully executed. Terminal.
PENDING_CANCELCancel requested, awaiting confirmation.
CANCELEDCancelled. Terminal.
PENDING_REPLACEReplace requested, awaiting confirmation.
REJECTEDRefused (bad params, halted symbol, insufficient buying power). Terminal.
EXPIREDHit its time-in-force limit without filling. Terminal.
See the full status and field-enum reference on the Account Updates WebSocket page.

​
Where to watch and listen for updates

All order status changes flow over the Account Updates WebSocket, on the account topic, as events named account.order.
  1. Connect to wss://api.aries.com/v1/accounts/ws.
  2. Authenticate within 5 seconds with your access token.
  3. Subscribe to the account topic with your accountId.
  4. Receive an initial snapshot (current open orders, positions, balance), then a live stream of account.order events as your orders change.
The per-type pages (Limit order, etc.) show the exact subscribe message and the order-event payload for that type. For the complete WebSocket protocol — authentication, all topics, reconnection, and every field — see the Account Updates WebSocket reference.
If the connection drops. A dropped socket means you may have missed events while disconnected. On reconnect: re-authenticate, re-subscribe to the account topic, and use the snapshot the server returns to reset your view. To be sure nothing was missed, also reload working orders over REST from Today’s Orders and reconcile against your local state before resuming.

​
Modifying and cancelling

Two more endpoints round out the module:

Replace (modify) an order

POST /v1/orders/replace — change price, quantity, or time-in-force on a working order. Each replace returns a new clOrdId you must use for the next replace.

Cancel an order

POST /v1/orders/cancel — cancel a working or partially-filled order by origClOrdId. Any quantity already filled is preserved.
Preview before you place. POST /v1/orders/preview accepts the exact same body as place-order and returns estimated cost, commission, buying-power impact, fees, and any warnings — without sending the order. Use it to show a confirmation screen. See Preview Order.

​
Next steps

Market order

The simplest order. Buy or sell now at the best available price.

Limit order

Set your price. Includes the full REST + WebSocket round-trip.

Single-leg option

Buy or sell one call or put.

Multi-leg option

Verticals, calendars, and ratio spreads in a single order.