Advanced Order Types Explained

Advanced order types are the vocabulary of electronic trading. Every order you send falls into one of three behavioral dimensions: how it prices itself, when it activates, and whether it links to other orders. Getting that taxonomy straight is what separates a strategy that executes predictably from one that produces surprises at the broker.

This reference covers the full range of order types available on electronic trading platforms, from the basics of market and limit orders through stop variants, trailing stops, linked order classes, time-in-force qualifiers, and institutional execution algorithms. Each section explains the mechanics, the trade-offs, and where a given order type belongs in an automated strategy's toolkit.

Not every order type belongs in every strategy. Knowing which ones to skip is just as useful as knowing how the others work.

Three Dimensions of Any Order

Pricing behavior

Every order defines how it will price itself: at whatever the market offers (market order), at a specified limit (limit order), or triggered by a stop price before becoming a market or limit order. Pricing behavior is the most fundamental dimension because it determines execution certainty versus price certainty, a trade-off every automated strategy must consciously choose.

Activation behavior

Some orders rest in the book immediately; others stay dormant until a trigger price is touched, at which point they activate and enter the market. Stop and stop-limit orders are activation-based: the stop price is not an execution price but a threshold that releases the order into the market as a market or limit order respectively. Trailing stops are a dynamic form of activation order where the trigger price moves with the market's high-water mark rather than sitting at a fixed level.

Linking behavior

A third dimension governs whether orders travel alone (simple), trigger a child order on fill (one-triggers-other, OTO), or pair a take-profit and stop-loss against a parent entry (bracket). Linking behavior is what separates a standalone entry from a fully bracketed trade with automatic risk management attached.

Price-Based Order Types

Market orders

A market order executes immediately at the best available price. Execution is guaranteed but the fill price is not, making slippage the primary risk. Market orders are appropriate when certainty of fill matters more than certainty of price, such as closing a position on a fast-moving stop signal where missing the fill entirely is the worse outcome.

Limit orders

A limit order will only execute at the specified price or better: for a buy, the fill must be at or below the limit price; for a sell, at or above. Limit orders control entry and exit price at the cost of fill certainty. The order rests in the book and may not execute if the market never reaches the limit.

In automated strategies, a limit price can be sent in the webhook payload via the limitPrice field. If omitted when orderType=limit is specified, the platform uses the current market price at execution time.

Stop and stop-limit orders

A stop order becomes a market order once the stop price is touched, combining activation logic with market-order pricing after the trigger. A stop-limit order becomes a limit order after the stop price is touched, adding price control after activation but reintroducing the risk of non-fill in a fast market. The stop price and limit price in a stop-limit order are distinct values: the stop triggers the order, the limit caps the fill price. Both can be specified in a webhook payload using the stopPrice and limitPrice fields under orderType=stop_limit.

Trailing Stops

How trailing stops work

A trailing stop sets its trigger at a fixed dollar amount or percentage away from the highest price reached since the order was placed, ratcheting upward for longs and downward for shorts. For a sell trailing stop, the stop price is always the high-water mark minus the trail amount; the stop never moves backward against the trade's favor. Trail amounts can be defined as a fixed dollar offset or as a percentage of the high-water mark, and only one of those two methods can be active at once.

Trailing stops in automated signals

A webhook payload can specify a trailing stop on entry using either trailAmount (fixed dollar offset) or trailPercent (percentage of high-water mark), but not both simultaneously. A stop-loss leg inside a bracket can also be defined as a trailing stop by setting StopLoss.type to trailing_stop and providing either StopLoss.trailAmount or StopLoss.trailPercent.

Broker support for trailing stops varies. The TradersPost paper broker does not support trailing stops, while Interactive Brokers does. When the connected broker does not support trailing stops, TradersPost falls back to the default order type configured in the strategy subscription settings.

Linked Order Classes

Bracket orders

A bracket order attaches both a take-profit limit order and a stop-loss order to a parent entry. When either child fills, the other is automatically canceled. Bracket support is broker-dependent; some brokers that accept a full bracket will reject a one-sided version of it, so a take-profit-only or stop-loss-only attachment may not be available on every connected broker.

For futures, bracket legs can be set as a market price offset from the entry price or as a dollar profit and loss target, using pnlAmount. An MNQ entry at 25,125.25 with a 100-point offset on each leg places take-profit at 25,225.25 and stop-loss at 25,025.25, regardless of what that price movement represents in dollar terms.

TradersPost routes bracket orders where the broker supports the bracket order class natively; a broker that cannot send a bracket natively has its exit legs simulated instead, so the stop and target still apply. Verifying your broker's supported order classes before relying on automated brackets is essential.

One-triggers-other (OTO)

An OTO order consists of a primary order and one child order. The child is held dormant until the parent fills, at which point the child is released to the market. OTO is distinct from a bracket in that it attaches only one child rather than a paired take-profit and stop, making it useful for placing a stop-loss without a corresponding take-profit. Like brackets, OTO availability is determined by whether the connected broker supports the OTO order class.

Simple orders

A simple order travels alone with no attached children. Any corresponding exit must be managed by a separate signal or manual action. Simple is the baseline order class supported by every broker; strategies that rely only on simple orders have the widest broker compatibility.

Time in Force

Day, GTC, and IOC

Time in force is a separate dimension from order type: it governs how long an unfilled order remains active, not how it prices itself. Day (DAY) cancels any unfilled portion at the end of the regular session. Good Till Canceled (GTC) keeps the order active across sessions until it fills or is manually canceled. Immediate or Cancel (IOC) fills whatever quantity is available at submission and cancels the remainder instantly, useful for avoiding partial resting orders.

Auction qualifiers: OPG and CLS

Market on Open (OPG) and Market on Close (CLS) are time-in-force qualifiers, not separate order types. They route an order to participate in the opening or closing auction rather than the continuous market. A Limit on Open or Limit on Close order pairs a limit price with the OPG or CLS qualifier, allowing price control within the auction. In a webhook payload, these are set via the timeInForce field: opg targets the opening auction, cls targets the closing auction.

FOK and GTD

Fill or Kill (FOK) requires the entire order quantity to fill immediately or the whole order is canceled. It differs from IOC in that partial fills are not accepted. Good Till Date (GTD) keeps an order active until a specified date rather than indefinitely, combining the persistence of GTC with an automatic expiration. Both are available as values in the timeInForce field of the webhook payload.

Institutional Execution Algorithms

TWAP and VWAP algos

TWAP (time-weighted average price) algorithms are designed to achieve the average price calculated across a defined time window by slicing a large order into smaller child orders spread over that period.¹ VWAP (volume-weighted average price) algorithms aim to achieve or outperform the VWAP benchmark calculated from the time the order is submitted to the close of the market, adjusting participation pace based on volume forecasts.² Both are institutional execution tools designed to minimize market impact when working large order sizes that would move the market if submitted all at once.

Iceberg and reserve orders

An iceberg (or reserve) order displays only a fraction of its total size in the order book, refreshing the visible quantity as each slice fills to avoid signaling the full size to the market. Platforms like Interactive Brokers offer a Dark Ice algo that works similarly, randomizing the display size and adjusting order placement based on calculated price probabilities.³ These are institutional tools for managing market impact of large positions; a retail automated strategy trading normal lot sizes has no use for them.

Why retail algos skip these

Retail automated strategies typically trade sizes that have negligible market impact, so slicing execution over time adds latency and complexity without a meaningful price benefit. Webhook-driven automation sends a single order per signal; TWAP and VWAP require ongoing order management that operates at the broker or platform level, not through a one-shot webhook payload. Choosing a market or limit order and sending it cleanly is the right approach for nearly every retail automated strategy.

Choosing the Right Order Type

Match order type to signal intent

Entry signals on liquid instruments with tight spreads tolerate market orders well. Entries on thinner or faster-moving instruments benefit from limit orders to control slippage. Stop-loss exits where missing the fill is more costly than a worse price favor market orders or stop (market) orders over stop-limit orders. Take-profit exits where price precision matters favor limit orders; a stop-limit on a take-profit risks non-fill if the instrument gaps through the limit.

• Liquid, tight-spread entries: market orders are fine
• Thin or fast-moving entries: use limit orders
• Stop-loss exits: prefer stop (market) over stop-limit when fill certainty matters
• Take-profit exits: limit orders; avoid stop-limit which can result in no fill on a gap
• Auction participation: set timeInForce to opg or cls, not a separate order type

Verify broker support before deploying

Not every broker supports every order type or order class. Sending an unsupported order type causes a fallback to the default order type configured in the strategy subscription settings, and that fallback happens silently. Bracket and OTO availability must be confirmed for the specific broker before a strategy depends on attached child orders for risk management.

TradersPost falls back to the strategy subscription's default order type when a broker does not support the order type specified in the webhook payload, so misconfigured order types fail silently rather than with an error. Checking the trade signal logs after the first few paper trades confirms the actual order type that was submitted to the broker.

Paper trading the full order flow before going live is the most reliable way to confirm that the order type, class, and time-in-force combination behaves as expected at your broker. Run at least a handful of paper trades covering your entry, take-profit, and stop-loss paths before switching to a live account. The signal logs will show exactly what was submitted and in what form.

Bottom Line

• Order types split into three dimensions: pricing behavior, activation behavior, and linking behavior. Every order you send operates across all three simultaneously.
• Market, limit, stop, stop-limit, and trailing stop cover the pricing and activation needs of most retail automated strategies. TWAP, VWAP, and iceberg orders are institutional tools with no practical role in webhook-driven retail automation.
• Bracket and OTO order classes automate exit management but depend on broker support. Simple is the only class guaranteed to work everywhere.
• Time in force is a separate field from order type. Auction participation (OPG, CLS) lives there, not in the order type field.
• Silent fallbacks on unsupported order types make paper trading the full order flow a prerequisite, not an option, before going live.

Frequently Asked Questions

What is the difference between a stop order and a stop-limit order?

A stop order becomes a market order once the stop price is touched, guaranteeing execution but not the fill price. A stop-limit order becomes a limit order after the stop price is triggered, capping the fill price but risking no fill at all if the market moves through the limit before the order can execute. The stop-limit adds price control at the cost of execution certainty, which is a meaningful trade-off in fast or gapping markets.

Do I need TWAP or VWAP orders for automated trading?

Almost certainly not. TWAP and VWAP algorithms are designed to minimize market impact when working large order sizes that would move the market if submitted as a single order.⁴ Retail automated strategies trading normal lot sizes have negligible market impact, so slicing execution over time adds latency without a meaningful price benefit. Webhook-driven automation also sends one order per signal; TWAP and VWAP require ongoing order management at the broker level that a single webhook payload cannot orchestrate.

What is a bracket order and how does it differ from a simple stop-loss?

A bracket order attaches both a take-profit limit order and a stop-loss order to the parent entry as a single linked unit. When either child fills, the platform automatically cancels the other. A simple stop-loss is a standalone order with no linked take-profit; it must be managed independently and does not automatically cancel a separate take-profit if hit. Bracket support depends on the broker; some brokers support the full bracket but not a one-sided version, so the available configuration options vary by connected broker.

Where do market-on-close and market-on-open orders fit in?

Market on Open (OPG) and Market on Close (CLS) are time-in-force qualifiers that route an order to participate in the opening or closing auction rather than the continuous session. They are not separate order types; they modify when and where a market or limit order executes by targeting the auction mechanism. In a webhook payload, these are set via the timeInForce field using the values opg and cls respectively.

What happens if I send an unsupported order type in my webhook?

If the connected broker does not support the order type specified in the webhook payload, the platform falls back to the default order type configured in the strategy subscription settings. The fallback happens silently, so the trade may execute but with a different order type than intended. Reviewing trade signal logs after paper trading confirms what was actually submitted. Verifying the broker's supported order types and order classes before deploying a live strategy prevents unexpected behavior from these silent fallbacks.

References

¹ Interactive Brokers TWS User Guide: TWAP
² Interactive Brokers TWS User Guide: VWAP
³ Interactive Brokers TWS User Guide: Algorithmic Trading (Dark Ice)
⁴ Interactive Brokers TWS User Guide: VWAP