Parent/Child Orders

Parent/child orders describe an order structure where one main order can include related child orders, such as take-profit or stop-loss instructions.

A parent/child order structure helps represent trading instructions that are connected instead of isolated. The parent order is the main instruction, such as opening or placing a position. A child order is a related instruction that depends on the parent order in some way. For example, a trader may place a main buy order and attach a take-profit order and a stop-loss order to manage what happens next. These attached instructions are not always immediately executable because they may depend on the parent order being filled, triggered, canceled, or updated. In market data systems, parent/child orders matter because the order book may include records that are related but not all equally tradable at the same moment. A reconstruction engine needs to understand whether a child record contributes active liquidity or simply describes a contingent instruction. Without this distinction, a reconstructed order book can overstate available depth or misread the lifecycle of an order. Parent/child relationships are especially important in advanced derivatives and crypto trading venues where conditional order logic is common. They also help analysts trace how one trading decision can create several connected order events over time. Cleanly modeling these relationships makes historical replay, validation, and execution analysis more accurate.

Parent/child orders matter because they show that not every order record should be treated as standalone liquidity. For developers, recognizing these relationships helps prevent incorrect order book reconstruction and cleaner downstream analytics.

Parent and child orders are linked trading instructions where one main order has related follow-up or dependent orders. The parent order usually represents the primary action, such as opening a position or placing a core limit order. Child orders represent instructions that are tied to that parent, such as taking profit, stopping loss, or reacting to a trigger. These child orders may not become active until a specific condition is met. This structure is useful because real trading workflows often involve more than one instruction. In market data, the relationship helps explain why several records may belong to the same broader trading strategy.

Parent/child orders affect reconstruction because the system must decide which records count as active executable liquidity. A child order may appear in the data feed, but it may be contingent rather than live in the visible book. If a reconstruction engine treats every child record as active depth, the book can become inaccurate. The system also needs to preserve the relationship between parent and child records when updates, fills, cancellations, or triggers arrive. This is especially important when replaying events from a raw journal or debugging differences between expected and reconstructed state. Correct handling makes the book more reliable for analytics, simulation, and monitoring.

Parent/child orders and conditional orders are related, but they are not always the same thing. A conditional order is defined by a trigger or condition that controls when it becomes active or executable. A child order can be conditional, such as a stop-loss order attached to a parent position. However, a child order is mainly defined by its relationship to another order. Some child records may exist for tracking, grouping, or lifecycle purposes rather than only for trigger logic. The two ideas often overlap in advanced trading systems, so market data consumers should model both relationship and condition fields carefully.

A trader places a parent order to buy a crypto perpetual contract at a specific price. At the same time, the trader attaches one child order to sell at a profit target and another child order to exit if the market falls. The two child orders are connected to the parent order and may only become relevant after the parent order is filled. If a market data system records all three instructions, it needs to know which records are active liquidity and which are contingent instructions.

CoinAPI’s Market Data API helps teams collect structured crypto market data that can support analysis of complex order activity. For use cases involving detailed order book reconstruction, developers can use normalized market data fields to preserve order identifiers, lifecycle changes, and related context where supported by the venue. Parent/child order relationships are especially useful when building systems that need to distinguish active depth from contingent instructions. This helps trading teams, researchers, and infrastructure providers build cleaner replay, validation, and monitoring workflows.

Crypto API made simple: Try now or speak to our sales team