How to Check Whether a Binance Spot Order Is Partially Filled

Understanding Order Status Fields

1. The status field in Binance’s order response indicates the current lifecycle stage: NEW, PARTIALLY_FILLED, FILLED, CANCELED, or REJECTED.

2. A value of PARTIALLY_FILLED means at least one fill has occurred but the full origQty remains unexecuted.

3. This status is returned immediately upon the first partial execution, regardless of whether further fills are expected.

4. It persists until either the remaining quantity is fully executed or the order is manually canceled.

5. Status updates are delivered via REST response on get_order and streamed in real time through user data stream events.

Analyzing Execution Quantities

1. Compare executedQty against origQty: if executedQty is greater than zero but less than origQty, the order is partially filled.

2. Examine cummulativeQuoteQty — it reflects the total quote asset value matched so far and must be non-zero when partial fills exist.

3. Inspect the fills array: a non-empty list confirms at least one trade execution has taken place.

4. Each entry in fills contains price, qty, commission, and tradeId, providing granular evidence of partial execution.

5. Note that executedQty and cummulativeQuoteQty are string-typed decimal values; direct float comparison must be avoided to prevent precision loss.

Using the get_order API Endpoint

1. Call trade.get_order(symbol='BTCUSDT', orderId=123456789) with valid credentials and correct symbol casing.

2. Parse the data object inside the response — do not rely solely on top-level code or msg fields.

3. Extract status, executedQty, origQty, and fills from the nested data payload.

4. Validate numeric consistency: ensure executedQty ≤ origQty and cummulativeQuoteQty matches the sum of price × qty across all fills.

5. Treat any deviation from this invariant as an anomaly requiring manual reconciliation or upstream investigation.

Monitoring Through User Data Stream

1. Subscribe to the executionReport event under a valid user data stream WebSocket connection.

2. Filter messages where eventType equals executionReport and symbol matches the target trading pair.

3. Detect partial fills by checking for executionType equal to TRADE while orderStatus remains PARTIALLY_FILLED.

4. Accumulate lastExecutedQuantity and lastPrice from each executionReport to reconstruct fill history without polling.

5. Use eventTime to sequence fills chronologically and identify gaps or duplicate reports caused by network jitter or reconnection.

Frequently Asked Questions

Q: Can PARTIALLY_FILLED status revert to NEW after being reported?A: No. Binance’s order state machine is strictly monotonic. Once PARTIALLY_FILLED is issued, it transitions only to FILLED, CANCELED, or EXPIRED.

Q: Does get_orders_pending include partially filled orders?A: Yes. get_orders_pending returns all open orders, including those with PARTIALLY_FILLED status and remaining unfilled quantity.

Q: Is there a delay between a fill occurring and the status update appearing in get_order?A: Under normal conditions, the REST API reflects the latest state within 100 milliseconds. Higher latency may occur during exchange maintenance windows or regional API routing failures.

Q: What happens to the fills array when an order is canceled after partial execution?A: The fills array remains intact and unchanged. Cancellation affects only future execution; historical fills are immutable and preserved in the order record.