Order Lifecycles

Crypto Order Lifecycle

Track every stage of order execution across multiple crypto exchanges.

Submitting an order is only the beginning. Between the moment an application submits an order and the moment it is filled, canceled, or rejected, the order progresses through a series of well-defined states. Orders are validated, routed to an exchange, accepted into an order book, partially executed, canceled, or completed. Understanding these transitions is essential for building reliable trading systems.

CoinAPI EMS provides complete visibility into the entire order lifecycle through a standardized execution model. Every order progresses through one of several documented lifecycle paths depending on how it is processed and executed.

Explore the EMS Trading API Contact Sales

What Is an Order Lifecycle?

An order lifecycle describes every state an order passes through from submission until it reaches its final outcome. Instead of treating an order as simply “open” or “closed,” professional trading systems continuously monitor how that order evolves over time.

For developers building trading infrastructure, the order lifecycle becomes the single source of truth for execution monitoring, portfolio updates, reporting, and operational diagnostics.

For example, an order may:

Be received by the trading system.
Be routed to an exchange.
Become active in the exchange order book.
Be completely executed.
Be canceled.
Be rejected before execution.

Why Order Lifecycle Tracking Matters

Knowing whether an order exists isn't enough. Professional trading applications need to understand how the order reached its current state.

Instead of polling different exchanges and translating proprietary status codes, applications receive a consistent lifecycle model regardless of where the order is executed.

Order lifecycle tracking helps developers:

Monitor orders in real time.
Detect execution problems quickly.
Display accurate order status to users.
Build execution and audit reports.
Track partial fills as they occur.
Synchronize portfolios and positions.
Troubleshoot exchange-specific execution issues.
Build automated trading and risk management systems.

Order Lifecycle in CoinAPI EMS

Every order submitted through CoinAPI EMS follows a well-defined lifecycle. As the order moves from your application to the exchange, the EMS tracks every significant event, from initial submission and routing to execution, cancellation, or rejection. Each supported exchange is normalized into the same lifecycle model, giving developers a consistent way to monitor and manage orders regardless of the underlying trading venue.

Order Statuses

Status	What It Means	Terminal
RECEIVED	The EMS has received the order from your application and started processing it.	✗
ROUTING	The order is being delivered from the EMS to the selected exchange.	✗
ROUTED	The order has been sent to the exchange but is not yet active in the order book.	✗
NEW	The order is active in the exchange order book and waiting for execution.	✗
PARTIALLY_FILLED	Part of the order has been executed while the remaining quantity stays active in the order book.	✗
PENDING_CANCEL	A cancellation request has been sent to the exchange and is awaiting confirmation.	✗
FILLED	The order has been completely executed and removed from the order book.	✓
CANCELED	The order has been canceled and removed from the order book.	✓
REJECTED	The order was rejected and never became active for execution.	✓

The exact sequence depends on how the order is processed. Terminal statuses (FILLED, CANCELED, and REJECTED) mark the end of the order lifecycle and no further state transitions occur.

Common Order Lifecycles

Not every order follows the same path. Some execute immediately, others fill gradually over time, while some are canceled or rejected before they ever become active.

Fully Executed Order

The simplest lifecycle is a successful order that reaches the exchange and is completely filled.

fully-executed

RECEIVED → ROUTING → ROUTED → NEW → FILLED

This is common when sufficient liquidity exists at the requested execution price.

Partially Filled Order

Large orders or orders placed at less liquid price levels may execute gradually.

partially-filled

RECEIVED → ROUTING → ROUTED → NEW → PARTIALLY_FILLED → FILLED

The order remains active after each partial execution until the remaining quantity is filled.

Canceled Order

An order may be canceled by the application or according to its execution rules before it is completely filled.

canceled

RECEIVED → ROUTING → ROUTED → NEW → PENDING_CANCEL → CANCELED

The cancellation request is first acknowledged before the exchange confirms that the order has been removed from the order book.

Rejected Order

Some orders never reach the order book.

rejected

RECEIVED → REJECTED

Typical reasons include invalid parameters, unsupported values, insufficient funds, exchange validation failures, or exchange connectivity issues.

Monitor Orders in Real Time

Knowing the current order status is useful. Knowing every status change as it happens is even more valuable.

CoinAPI EMS delivers execution reports that allow applications to maintain an up-to-date view of every active order. Developers receive both the current state of an order and its complete status history.

Execution reports include the current order status, status history, filled quantity, remaining quantity, average execution price, exchange identifiers, timestamps, and fill details — available through WebSocket and FIX, with REST endpoints for querying order state.

Applications can:

Track open orders across multiple exchanges.
Receive execution updates as they occur.
Record complete status histories for auditing.
Monitor fills and remaining quantities.
Synchronize trading dashboards in real time.
Build alerts around execution events.

Every Status Change Is Preserved

CoinAPI EMS doesn't simply return the current order status. Execution reports include a timestamped status_history showing every transition an order has gone through from RECEIVED to its terminal state — along with fill information when executions occur.

This is explicitly documented via the status_history field in execution reports.

This makes it possible to:

reconstruct the complete order lifecycle
troubleshoot execution issues
audit trading activity
visualize order progress
calculate routing and execution latency

What You Can Build with Order Lifecycle Data

A normalized order lifecycle becomes the foundation for much more than order tracking. It enables applications to understand how execution happens across every connected exchange using one consistent model.

Because CoinAPI EMS abstracts exchange-specific workflows behind one standardized lifecycle, developers can focus on building trading applications instead of translating dozens of proprietary execution models.

Common use cases include:

Multi-exchange trading platforms.
Order management systems (OMS).
Algorithmic trading infrastructure.
Execution monitoring dashboards.
Compliance and audit reporting.
Risk management systems.
Portfolio and position monitoring.
Trading analytics and execution quality reporting.

Order Lifecycles

Build Trading Systems with Complete Execution Visibility

Every order tells a story, from submission and routing to execution, cancellation, or rejection.

CoinAPI EMS gives your applications access to that complete story through a standardized order lifecycle, real-time execution reports, and unified APIs across multiple cryptocurrency exchanges. Whether you're building an algorithmic trading platform, an OMS, a monitoring dashboard, or institutional execution infrastructure, consistent lifecycle tracking makes it easier to understand, monitor, and optimize every trade.