TWS API order types
This catalog covers every construction on IBKR's official TWS API Basic Orders page, then the major compound and algorithmic families. Availability is a function of product, route, region, account permissions, TWS/server version, and sometimes live versus paper trading. The final authority is the current IBKR order matrix plus ContractDetails.orderTypes/validExchanges.
Core directional orders
| Name | Encoding | Operation and edge cases |
|---|---|---|
| Market | orderType="MKT" | Executes at available prices; favors immediacy, provides no price protection, and can sweep far through a thin book. |
| Limit | LMT; lmtPrice | Buy at limit or lower / sell at limit or higher. It may never fill. Price must conform to the applicable market-rule increment. |
| Forex cash quantity | usually LMT/MKT; cashQty | Sizes by settlement-currency cash rather than base units where supported. Do not also send a conflicting totalQuantity. |
| Market-to-limit | MTL | Sends as market; an unfilled remainder becomes a limit at the execution price. A partial first fill determines the remainder's cap. |
| Market with protection | MKT PRT | Futures-oriented protected market order; unfilled quantity becomes a limit at an exchange-defined protection price. Protection is not your chosen limit. |
| Limit with manual-order time | LMT; lmtPrice, manualOrderTime | Records the operator/manual submission time for reporting workflows. The timestamp is metadata, not an activation time; use goodAfterTime for activation. Server-version and institutional requirements apply. |
| Block | LMT; blockOrder=True | Large-block handling, historically ISE options specific. Size/routing eligibility is enforced by the venue. |
| Sweep-to-fill | LMT; sweepToFill=True | SMART-routed limit order that simultaneously addresses successive price levels for speed; never exceeds the limit. |
| Discretionary | LMT; lmtPrice, discretionaryAmt | Displays the limit while permitting a hidden discretionary range. Amount must obey tick precision; the hidden range changes execution economics. |
Triggered orders
| Name | Encoding | Operation and edge cases |
|---|---|---|
| Stop | STP; auxPrice=stop | On trigger becomes market. Trigger is not a guaranteed fill price; gaps can be severe. Buy stop normally lies above and sell stop below the market. |
| Stop limit | STP LMT; auxPrice=stop, lmtPrice=limit | On trigger becomes limit. Provides price protection but can remain unfilled after the market passes the limit. |
| Market if touched | MIT; auxPrice=trigger | Buy is normally triggered as market falls to/below the trigger; sell as it rises to/above. Semantically opposite to a protective stop. |
| Limit if touched | LIT; auxPrice=trigger, lmtPrice=limit | Touch activates a limit order. It can trigger and not fill. |
| Stop with protection | STP PRT; auxPrice=stop | Triggered futures order executes within an exchange protection band; remainder becomes a protected limit. |
| Trailing stop | TRAIL; auxPrice=absolute trail or trailingPercent; optional trailStopPrice | Favorable movement ratchets the stop; adverse movement does not. On trigger becomes market. Do not set competing trail amount forms. |
| Trailing stop limit | TRAIL LIMIT; trail amount/percent, lmtPriceOffset, optional trailStopPrice | Ratchets a trigger and, after trigger, submits a limit offset. Price protection introduces non-fill risk. Some TWS presets auto-populate offsets, so explicitly unset conflicting fields. |
| Adjustable stop family | parent plus triggerPrice, adjustedOrderType, adjustedStopPrice, adjustedStopLimitPrice, adjustedTrailingAmount | When the adjustment trigger is reached, modifies the parent into the specified stop/stop-limit/trailing type rather than transmitting a separate child. Do not confuse adjustment trigger with stop trigger. |
Open, close, and auction
| Name | Encoding | Operation and edge cases |
|---|---|---|
| Market on open | MKT, tif="OPG" | Participates in the opening process. Cutoffs and imbalance handling are venue-specific. |
| Limit on open | LMT, tif="OPG", lmtPrice | Opening participation with a limit; may not fill if the opening price violates it. |
| Market on close | MOC | Seeks the official close without user price protection. Venue cutoff/cancel rules are strict. |
| Limit on close | LOC; lmtPrice | Closing-auction order that fills only at a qualifying close price. |
| Auction | MTL, tif="AUC", lmtPrice | Entered before the open for the calculated opening price; official behavior may resubmit an unfilled remainder as a limit. |
| Auction limit | LMT; auctionStrategy | BOX option price-improvement auction participation with a limit. Direct routing and penny improvement rules apply. |
| Auction pegged to stock | PEG STK; delta, startingPrice, optional stock reference/range | BOX option auction price changes with the underlying by signed delta. Stock range can cancel the order. |
| Auction relative | REL; auxPrice=offset, auction fields | BOX option auction relative pricing. It is not the same as generic SMART pegged-to-primary behavior. |
| Imbalance-only | supported auction type plus imbalanceOnly=True | Participates only in supported exchange imbalance mechanisms; availability/cutoffs are route-specific. |
Pegged and relative orders
| Name | Encoding | Operation and edge cases |
|---|---|---|
| Pegged to market | PEG MKT; auxPrice=offset, optional cap | Maintains a price relative to the same-side market. Official examples and accepted token can vary by server/route; verify contract order types. |
| Pegged to primary | REL; auxPrice=offset, lmtPrice=cap | Buy follows NBB and sell follows NBO by offset, capped by limit. Can become aggressive as quotes move. Often unavailable in paper. |
| Passive relative | PASSV REL; auxPrice=offset | Pegged order designed to remain passive and avoid crossing; venue repricing rules determine behavior. |
| Pegged to midpoint | PEG MID; auxPrice=offset, lmtPrice=cap | Tracks NBBO midpoint with direction-sensitive offset and cap. Requires a valid NBBO and supported route. |
| Pegged to stock | PEG STK; delta/reference fields | Option price is pegged to movements in its underlying stock. Delta sign and option right matter. |
| Pegged to benchmark | PEG BENCH; referenceContractId, isPeggedChangeAmountDecrease, peggedChangeAmount, referenceChangeAmount, referenceExchangeId, lmtPrice | Price moves based on a reference contract's change from a reference value, not simply the traded contract's quote. |
| IBKR ATS pegged-to-best | PEG BEST; ATS fields such as minTradeQty, minCompeteSize, offsets | IBKRATS-only behavior. Routing, minimums, and whole/half-penny offsets are server-version dependent. |
| IBKR ATS pegged-to-mid | PEG MID with IBKRATS parameters | ATS midpoint behavior with venue-specific minimum and offset controls. Do not assume generic PEG MID parameters are interchangeable. |
| Midprice | MIDPRICE; optional lmtPrice cap | SMART-routed US-stock order that seeks NBBO midpoint or better. The optional cap is highest buy/lowest sell price; requires a valid NBBO and supported TWS/server version. |
Venue-specific and volatility orders
| Name | Encoding | Operation and edge cases |
|---|---|---|
| Box Top | BOX TOP | BOX option marketable order; unfilled remainder becomes a limit at the initial execution price. BOX route only. |
| Volatility | VOL; volatility, volatilityType, continuousUpdate, referencePriceType, optional lmtPrice and delta-neutral fields | Option order priced from implied volatility. Volatility type must be daily or annual as specified; underlying-price updates can reprice the order. Complex and entitlement-sensitive. |
| Scale | base order plus scaleInitLevelSize, scaleSubsLevelSize, scalePriceIncrement, and optional profit/reset fields | Breaks quantity into successively priced components. Invalid/missing level sizes and increments are rejected; fills alter subsequent levels. |
| Hedge | child order with parentId, hedgeType, hedgeParam | Creates supported delta/beta/FX/pair hedge behavior tied to a parent. Transmit sequence and account permissions are critical. |
Combo orders
First create a Bag contract with ComboLeg records. Order-level forms are:
| Name | Encoding | Meaning |
|---|---|---|
| Combo market | MKT | Market price for the combo where supported; legging and routing risk depends on native versus SMART handling. |
| Combo net limit | LMT; lmtPrice | Limit on net debit/credit. Confirm the sign convention in a paper account for the exact buy/sell leg construction. |
| Price per leg | LMT; orderComboLegs=[OrderComboLeg(price=...), ...] | Supplies leg prices. Number/order must match combo legs. |
| Relative limit combo | REL + LMT (official examples also show capitalization variants) | Relative behavior with an overall limit. |
| Relative market combo | REL + MKT | Relative combo without the same net limit protection. |
SMART combo routing parameters use TagValue entries in smartComboRoutingParams; valid tags are venue/product specific. OCA support is restricted for SMART combos, and what-if calculations may be unavailable.
Compound order structures (not orderType tokens)
Bracket
IB.bracketOrder(action, quantity, limitPrice, takeProfitPrice, stopLossPrice) returns parent, take-profit child, and stop-loss child. The parent and first child have transmit=False; the last child has transmit=True, causing the group to transmit. Place all three in order. A process crash between sends can leave an untransmitted partial structure; reconcile it.
One-cancels-all
IB.oneCancelsAll(orders, ocaGroup, ocaType) assigns the group. Type 1 cancels remaining orders with block, type 2 proportionally reduces with block, and type 3 proportionally reduces without block. Partial fills and overfill risk differ. OCA is coordination, not a cross-venue atomic transaction.
Parent/child
Set child parentId to the parent's API order ID. Stage with transmit=False until the last intended child is ready. Child quantities should match supported parent rules, and children may remain held until the parent fills.
Algorithmic orders
Set algoStrategy and exact algoParams: list[TagValue]. Official sample tokens and parameters are:
| Strategy | algoStrategy | Parameters shown by the official API sample |
|---|---|---|
| Adaptive | Adaptive | adaptivePriority (Urgent, Normal, or Patient) |
| Arrival Price | ArrivalPx | maxPctVol, riskAversion, startTime, endTime, forceCompletion, allowPastEndTime |
| Close Price | ClosePx | maxPctVol, riskAversion, startTime, forceCompletion |
| Dark Ice | DarkIce | displaySize, startTime, endTime, allowPastEndTime |
| Accumulate/Distribute | AD | componentSize, timeBetweenOrders, randomizeTime20, randomizeSize55, giveUp, catchUp, waitForFill, activeTimeStart, activeTimeEnd |
| Percentage of Volume | PctVol | pctVol, startTime, endTime, noTakeLiq |
| TWAP | Twap | strategyType, startTime, endTime, allowPastEndTime |
| VWAP | Vwap | maxPctVol, startTime, endTime, allowPastEndTime, noTakeLiq, speedUp |
| Price Variant % Volume | PctVolPx | startPctVol, endPctVol, startTime, endTime, noTakeLiq, speedUp |
| Size Variant % Volume | PctVolSz | startPctVol, endPctVol, startTime, endTime, noTakeLiq |
| Time Variant % Volume | PctVolTm | startPctVol, endPctVol, startTime, endTime, noTakeLiq |
| Balance Impact Risk | BalanceImpactRisk | maxPctVol, riskAversion, forceCompletion |
| Minimize Impact | MinImpact | maxPctVol |
Some official regional examples use maxPctVol4Px, minPctVol4Px, or deltaPctVol. Treat the tag set as a schema: values are strings, booleans are normally encoded as "1"/"0", percentages have strategy-specific ranges, and an unknown/misspelled tag is not safely ignored.
Do not invent tags. Use the current official IB algorithms reference. Common parameters include start/end time, participation percentage, urgency/risk aversion, allow-past-end-time, force completion, and component/display size. Time parameters must be in the future where required (for example, error 167 for a past VWAP start).
Conditions
Conditions do not create new order types. Append PriceCondition, TimeCondition, MarginCondition, ExecutionCondition, VolumeCondition, or PercentChangeCondition to Order.conditions, link with .And()/.Or(), and control behavior with conditionsCancelOrder and conditionsIgnoreRth.
A price condition needs a canonical conId, exchange, trigger price, and comparison direction. A condition can be satisfied during a data gap or based on a trigger method you did not intend; test both RTH settings. Conditions are unavailable for some contracts/order types.
Official sources: basic orders, order conditions, IB algorithms, and IBKRATS orders.