Understanding Order Status Through a Broker API

An order is a process, not a single event

When software sends an order, the request passes through several systems before its final outcome is known. The terminal may show that it sent a request, while the broker has not yet acknowledged it. An acknowledged order may still be open, partially filled, modified, cancelled or rejected. A strategy that treats every submission as an immediate position can misstate exposure and send follow-up orders based on incorrect assumptions. Learn the status names and transition rules in the broker’s official API documentation. Some status details can differ across APIs, order types and exchanges, so avoid assuming that one platform’s labels map exactly to another’s.

Reconcile acknowledgements with broker records

After submitting an order, use the broker-provided identifier and status response to track its progress. If the client times out, do not assume that the order failed: the broker may have accepted it while the response was lost. Query the order book or use the documented update stream to determine whether it exists. Reconcile the terminal’s view with the broker’s own interface, especially after restarts or connectivity interruptions. A reliable process distinguishes a request identifier from a confirmed order identifier and retains enough information to investigate a discrepancy. This is particularly important when multiple strategies or operators can act on the same account.

Handle partial fills and changes explicitly

A partial fill means that some, but not necessarily all, of the requested quantity has executed. The remaining quantity can still be open or may be cancelled, depending on the order and broker response. A strategy should calculate exposure from confirmed fills, not just the requested quantity. If an order is modified or cancelled, confirm the resulting broker status before submitting a replacement. Otherwise, both the original and replacement might remain active. Define how the system responds to a rejection, a partial fill, a late update and a cancellation that cannot be confirmed. Make the chosen behavior visible to the operator rather than hiding it inside an unexplained status label.

Build a clear reconciliation checklist

When displayed status and broker records do not agree, pause new strategy actions that depend on the uncertain position. Compare timestamps, order identifiers, instrument, side, requested quantity, filled quantity and remaining quantity. Check whether an update arrived late or whether the order was changed through another channel. Preserve relevant diagnostic events without exposing credentials or personal data. Resume only when the account state is understood and the strategy’s position matches confirmed broker information. Test failure scenarios in a permitted environment wherever possible. Accurate order handling improves control and auditability, but neither status tracking nor automation guarantees a particular fill price or trading result.