What to expect from an order between preflight and the transaction ledger: validation, bracket legs, tracking, fill details, and matching executions back to the orders that created them.
The single-leg and multi-leg preflight endpoints are non-mutating. They return the estimated cost and impact of an order, including commission and fees, without placing it.
A successful preflight is not a guarantee that placement will succeed. Some checks only run at placement. For example, an account without crypto enabled can pass preflight and then be rejected with error 50154. See Crypto entitlement.
Recommended
A bracket pairs an entry order with take-profit and/or stop-loss exit legs. See Placing your first bracket order for how to place one.
| Behavior | Result |
|---|---|
| Time in force and expiration | Exit legs inherit the entry's. A DAY entry gets DAY exit legs, and a GTD entry gets exit legs with the same expirationTime. |
| An invalid leg | Every leg is validated against the live market at submission. If any leg is invalid, the whole bracket is rejected with 400 and nothing is placed. |
| Cancelling an unfilled entry | Cancels both exit legs. |
| Manually cancelling one exit leg | Does not cancel the other exit leg. Cancel it separately if you want both gone. |
There is no endpoint that lists every order on an account. Use these instead:
| To find | Use |
|---|---|
| Open orders | Get portfolio v2 |
| One order you placed | Get order with its orderId |
| Recent orders matching criteria | Search orders, which returns up to 500 orders created in the last 30 days |
| Posted transactions | Get history |
To follow orders in real time without polling, use the Order Updates WebSocket. It pushes the complete order every time it changes. For individual fills, use the Trades WebSocket, which pushes each trade as it executes. Delivery is at-most-once with no replay, so you still use the REST API to load state after every connect.
If you poll instead, the rate limit is 10 requests per second per account, across all endpoints. Requests over the limit return 429.
Recommended
429 responses with exponential backoff.Get order reports fills two ways: as aggregates in filledQuantity and averagePrice, and as individual fills in the trades array. Each trade has these fields:
| Field | Description |
|---|---|
tradeId | Trade ID |
instrument | Instrument that was traded |
side | BUY or SELL |
quantity | Quantity filled in this trade |
price | Price per unit of this trade |
timestamp | When the trade executed |
marketIdentificationCode | Market identifier code of the venue that executed the trade |
marketIdentificationCode is an ISO 10383 market identifier code, such as XNYS for the New York Stock Exchange or XNASfor Nasdaq. There's no fixed set of values, because a fill can execute on any venue the order is routed to. Look up a code in the ISO 10383 registry.
Trades don't include fees. For the fees of an execution, use the transaction history once it posts.
To receive each trade as it executes instead of reading it from Get order, use the Trades WebSocket. Its trades have the same fields, plus orderId, accountNumber, and a status that tells you if a trade was cancelled.
Get history rows don't include the ID of the order that created them. Each row has these fields:
| Field | Description |
|---|---|
id | Transaction ID |
timestamp | When the transaction happened |
accountNumber | Account the transaction happened on |
type | TRADE, MONEY_MOVEMENT, or POSITION_ADJUSTMENT |
subType | Subtype of the transaction |
symbol | Symbol of the transaction |
securityType | Security type of the transaction |
side | BUY or SELL, for trades |
direction | INCOMING or OUTGOING |
quantity | Quantity of the transaction |
principalAmount | Principal amount of the transaction |
fees | Fees of the transaction |
netAmount | Net amount of the transaction |
description | Description of the transaction |
A filled trade isn't always in history right away. The ledger can post after the order shows as filled.
Recommended
orderId, symbol, side, quantity, and submission time.