How Options Bot Orders Get Filled: Limit Prices, Multi-Leg Orders, Partial Fills, and Rejections

Options bot order execution starts when a trading rule produces a signal, but it does not end until the brokerage records actual executions and the account reflects the resulting position. Between those points, an order can be acknowledged, work without filling, execute in part, fill completely, expire, be canceled, or be rejected. Those events are easy to compress into a single “trade” on a dashboard, but they answer different questions.

This guide follows that live order lifecycle. It is not a guide to choosing a profitable strategy, estimating historical returns, sizing a portfolio, or managing exercise and assignment. Those subjects have their own backtest, position-sizing, and assignment guides. Here, the question is simpler and more immediate: what actually happened after an automated trade idea became an order?

Order handling varies by brokerage, venue, product, account permission, and market condition. Nothing here implies that OptionBots guarantees a fill, uses a particular router, retries rejected orders, automatically recovers from partial fills, or reconciles brokerage positions in a particular way. Verify supported behavior and current broker procedures before enabling live automation. Options involve substantial risk; read the risk disclosure before trading.

What Happens Between a Bot Signal and a Confirmed Position?

A signal is the outcome of a rule: for example, a user-defined condition says an entry is eligible. A signal is not itself an order. The workflow must still construct a request identifying the correct contracts, sides, quantities, price instructions, and account. That request may then be submitted to a brokerage.

An acknowledgement indicates that a system received or processed some stage of the request. It does not necessarily mean an exchange accepted it, a counterparty was found, or any contract traded. A working order remains eligible to execute under its terms, subject to its validity and the broker's or venue's handling. Status labels and when they update depend on the firm; distinguish a local “sent” notification from an actual brokerage order identifier and status.

An execution is a transaction for a stated number of contracts at a stated price. One order may generate several executions. A confirmed position is the exposure actually reflected in the brokerage account after those executions and any other account activity. The position can differ from the original request if less than the requested quantity filled, an order was modified, or other trades affected the account.

Think of this as a sequence of questions, not a guaranteed sequence of states: Did the rule fire? Was an order actually transmitted? What did the broker acknowledge? How much remains open? Which fills were recorded? What does the position view now show? An error message or delayed update can make these answers temporarily disagree.

Why Bid, Ask, and Midpoint Are Not Fill Promises

The bid is a displayed price at which a buyer may be willing to transact; the ask is a displayed price at which a seller may be willing to transact. The difference is the quoted bid-ask spread. The midpoint is arithmetic between them, useful as a reference but not necessarily available as a fill. Quotes and displayed sizes can change before an order reaches the market.

Hypothetical example: A call shows a $2.00 bid and a $2.20 ask, making the displayed midpoint $2.10. A buy order with a $2.10 limit might execute, work without a fill, or fill only part of its requested quantity. It cannot be assumed to trade immediately because the midpoint is not an offer from a seller. A $2.20 displayed ask does not necessarily cover every contract the bot wants to buy either.

Quoted size refers to displayed interest at a price, not an assurance about all available liquidity. Some interest is not displayed, quotes can update, and the available market for a multi-leg package is not simply the sum of static screenshots of its individual legs. Volume and open interest describe trading activity or outstanding contracts; neither guarantees an immediate executable price or size for this order.

For an automated workflow, quote age matters as much as quote value. A delayed, stale, or fast-changing quote can make a calculated limit appear reasonable when the current market has moved. Record the quote context used to form an order, but use actual execution reports—not the earlier midpoint—to determine what happened.

Limit Versus Market Orders: Different Trade-Offs

A limit order expresses a price boundary. For a buy, it generally specifies the maximum acceptable price; for a sell, the minimum. It controls the permitted price under the order's terms, but not whether the order fills, how long it takes, or whether it fills completely. A nonmarketable limit can rest while the market moves away.

A market order prioritizes seeking execution at available prices rather than setting an explicit price limit. That does not promise an immediate fill at the last quote, especially in a fast or thin market. Its final price can differ materially from the price visible when the signal fired. Applicable order types, protections, and handling differ across products and brokerages.

There is no universally correct order type or limit offset for options bots. A trader must weigh price control against nonexecution risk and check the particular broker's supported order instructions. For a spread, a net debit or credit limit describes the package price; it should not be confused with a separate limit on each option leg. The brokers page lists the currently presented OptionBots connections, but specific order-type support and account permissions must be confirmed with the brokerage.

How Do Multi-Leg and Complex Orders Work?

Cboe's current complex-order documentation defines a complex order as two or more different option-series “legs” submitted to the exchange as one order. At Cboe, if such an order fills, it executes within the specified net price and leg ratio; that is different from submitting independent orders for each leg. This is a description of Cboe's exchange handling, not a promise that every brokerage will submit a strategy in this form or that every exchange applies identical rules.

The net price combines the leg prices in their required proportions. A package may be entered for a net debit (payment) or net credit (receipt). Cboe's net-price explanation shows why the ratio matters: multiply each leg's price by its quantity in a single strategy unit, then combine the purchases and sales. A net limit is not a guarantee of an individual execution price for either leg in isolation.

Hypothetical example: A one-to-one vertical spread buys one option for $3.00 and sells another for $1.00 in a single package. Its illustrated net debit is $2.00 per spread, or $200 before costs for a standard 100-multiplier contract. If the order requests four spreads at a $2.00 net-debit limit, the request is for four complete one-to-one units at no more than that package debit under the assumed order terms—not a request to buy four options regardless of whether the short legs execute.

Cboe's ratio specification says the ratio can allow smaller partial executions while preserving the proper leg proportions. Its complex-order overview describes eligible orders interacting with the complex order book or with individual-leg quotes and orders under Cboe's conditions. Eligibility and matching rules vary by exchange, product, and order type; a trader should not infer venue behavior from the strategy name alone. The credit-spread and iron-condor guides explain the structures, while this section addresses only their order execution.

Whole and Partial Executions: Count What Filled

A full fill means the requested order quantity has executed. A partial fill means some, but not all, requested quantity executed; an unfilled remainder may still be working or may later be canceled or expire. The phrase “partial fill” does not by itself say whether an order's legs became unbalanced. That depends on whether the broker sent a packaged complex order or separate leg orders and on the venue's handling.

Continue the hypothetical four-spread order above. If an eligible Cboe complex order fills two of the four one-to-one spread units and two remain open, the executed portion preserves two long and two short option contracts in the specified ratio. The account has exposure from two spreads, not four. The unfilled two are not a position. The price and timing of any later fills may differ, subject to the order terms.

Submitting the legs separately is a different scenario. One leg might fill before the other, creating interim exposure. Do not describe a packaged complex order's ratio-preserving partial execution as automatic protection for a workflow that actually submits independent orders. If the order channel, leg balance, or execution reports are unclear, inspect the brokerage's records before making another trade.

What Can Happen to a Working Order?

A working order might fill in one execution, fill in several pieces, remain unfilled, be changed according to broker procedures, reach its time-in-force expiration, or be canceled. A canceled status applies to the unexecuted remainder; it does not undo contracts already filled. An expired order is no longer working under its time-in-force terms; it is not proof that an earlier partial execution vanished.

A rejection means a request was not accepted at some stage. Possible reasons include account approval, insufficient buying power, an invalid contract, an unsupported instruction, a price restriction, or a system issue. The broker's actual rejection reason and execution history matter more than guessing from a generic error. If a modification is rejected after earlier fills, those fills remain separate facts to verify.

Do not treat any terminal-looking message as the complete account story. A trader needs the order identifier, current status, cumulative filled quantity, remaining quantity, execution prices, and actual positions. Status transitions can be reported through multiple systems at different times.

Cancel/Replace and Delayed Acknowledgements

A request to cancel is a request, not evidence that the order has stopped being eligible to trade. A fill can occur while cancellation is pending. Similarly, a replace request to change price or quantity might not become effective before an execution; a firm may report the original order's status, replacement request, and new order identifier separately.

Hypothetical example: A trader requests cancellation of a working order for three spreads after seeing no immediate fill. The broker has not yet confirmed cancellation. One spread executes in the interval, and the broker then cancels the remaining two. The final position is one spread, not zero—even if a local interface briefly displayed “cancel requested.”

Delayed acknowledgements create a related risk. If a submission times out, the safe factual conclusion is only that its outcome is unknown until broker records establish whether the order exists. Repeating the same request without checking could create more exposure if the original order was accepted. This is an operational principle, not a claim that OptionBots implements any particular retry or duplicate-order safeguard.

Where Do You Reconcile the Final Result?

Use the brokerage's order history and execution reports to determine what was accepted, filled, canceled, expired, or rejected. Compare cumulative executions and outstanding quantities against the original intention. Then inspect the brokerage's current account positions—symbol, expiration, strike, side, quantity, and any other positions in that account. The account view can also reflect manual trades or other automation, so a bot signal alone cannot explain every change.

If the order view says “filled” but positions are not yet updated, do not assume either display is final without checking the brokerage's timing and records. If the position view shows only two spreads against a four-spread request, manage the actual two-spread exposure, not a modeled four-spread trade. Escalate discrepancies through the brokerage's documented support process before relying on a guessed state.

Reconciliation is separate from the later exercise and assignment lifecycle. The immediate question is which opening or closing transactions executed and what positions exist now. If the positions subsequently change due to another contract event, that requires a new check.

Why Backtest and Paper Fills May Look Cleaner

A backtest applies fill assumptions to historical data. A midpoint assumption can record a complete trade at one modeled price without capturing the time spent working, changing quotes, partial quantity, or a rejected order. The guide to reading options backtest results discusses how slippage, spreads, and liquidity affect such estimates; this guide focuses instead on observing an actual order's states.

Paper trading can help check order construction and monitor a forward-running workflow, but simulated matching and status updates may not mirror a live brokerage. The paper-trading bot guide covers that validation stage. Neither a backtest nor a paper execution establishes that a live market will provide the same size, price, timing, or status sequence. A template from OptionBots templates is a starting point for defining rules, not a guarantee of execution.

Pre-Deployment Order-Handling Checklist

1. Confirm the intended contract and account. Check symbol, expiration, strike, option type, side, and account permissions before an order is sent.
2. Document the intended order. Record requested quantity, single-leg or package structure, leg ratio, net debit or credit, price instruction, and time in force.
3. Verify broker support. Ask the actual brokerage which multi-leg and order types the account and connection support; do not assume every listed broker behaves alike.
4. Check quote context. Note bid, ask, displayed size, and quote age without assuming a midpoint or displayed size will fill.
5. Define status interpretation. Separate a local signal, submission, acknowledgement, working status, execution, and confirmed position.
6. Account for partial quantity. Decide how the user will inspect a partly filled package or independently submitted legs; never treat the requested amount as the filled amount.
7. Handle uncertainty explicitly. Treat delayed acknowledgement or pending cancel/replace as unknown until broker records confirm the outcome.
8. Review rejection information. Identify the broker's reported reason and check whether any related orders or earlier executions exist.
9. Reconcile after the event. Compare brokerage order history, executions, open orders, and current positions before assuming a strategy is active or closed.
10. Assign human oversight. Know who checks discrepancies and when the brokerage must be contacted; do not rely on an unverified automation feature to resolve them.

There is no order-setting recipe that guarantees execution. The practical objective is to make every transition observable, distinguish an intention from an actual transaction, and manage the position the brokerage confirms—not the position a bot was supposed to create.