Exchange API ACK, RESULT and FULL responses describe different amounts of order information, not three levels of execution success. In Binance Spot, ACK identifies the accepted order, RESULT adds an order-state snapshot, and FULL also includes fill details. Determine completion from the identified order's status and executed quantities, then reconcile subsequent events; a richer response does not promise that the whole order has filled.
The distinction matters when software decides whether to display a position, release reserved funds or start another workflow step. An accepted instruction and a completed purchase require different evidence. This guide focuses on the placement response itself; the existing guide to HTTP success and exchange error envelopes explains the preceding request-success checks.
What ACK, RESULT and FULL contain
These exact labels belong to Binance's documented newOrderRespType contract. They are useful examples of response design, but they are not a universal exchange vocabulary. Binance's Spot API glossary defines ACK as the identity-and-time response, RESULT as order information without fills, and FULL as order information including fills.
| Requested response | Evidence it supplies | Conclusion to avoid |
|---|---|---|
ACK | Symbol, exchange order ID, order-list ID, client order ID and transaction time | “There are no fills because no fill quantity appears.” |
RESULT | Order identity plus state fields such as status, original quantity, executed quantity and cumulative quote quantity | “There are no individual trades because no fills array appears.” |
FULL | Order-state information plus individual fills represented in the response | “FULL means the order is fully filled and no later event matters.” |
On Binance Spot's ordinary new-order endpoint, MARKET and LIMIT orders default to FULL; other order types default to ACK. That default is endpoint-specific. Record the response type requested or resolved from the documented default, especially when an adapter supports several order types. See Binance's new-order parameters.
Selecting FULL changes the response contract. It does not change a limit price, time in force or the availability of counterparties. Selecting ACK does not instruct the matching engine to hold off execution until the client requests more detail.
Response detail and order state are separate dimensions
An order can be accepted, partly executed or terminal. Its response can be concise or detailed. Store both dimensions rather than combining them into a local enum that runs from ACK to RESULT to FULL.
Binance defines NEW as accepted by the engine, PARTIALLY_FILLED as partly filled, and FILLED as completed. It also defines terminal outcomes such as CANCELED and EXPIRED. Its expiration definition includes orders that partially execute before the remainder expires. These are order statuses, separate from response types. Binance Spot order-status definitions.
Consequently, “terminal” and “fully executed” need separate labels too. A terminal order with some executions still created exposure, even if the requested quantity was never completed. Preserve the cumulative quantity alongside the status.
A client that receives only ACK knows less about execution than a client receiving RESULT. That is an observation boundary. It is not proof that the matching engine has done less work. Likewise, a FULL response with a working remainder must continue through the normal order lifecycle.
One order, three possible views
Consider an original hypothetical spot order in a fictional XYZ/USDT market. The account submits a good-till-canceled limit buy for 10 XYZ at a maximum of 25.20 USDT per XYZ. Assume the venue accepts the order and the following fills occur. Prices, identities and timing are illustrative; fees and other account activity are excluded.
| Moment | Underlying order event | Cumulative execution |
|---|---|---|
| A | Order accepted with one exchange order ID | 0 XYZ |
| B | Trade 101 buys 2 XYZ at 25.00; trade 102 buys 3 XYZ at 25.10 | 5 XYZ for 125.30 USDT |
| C | Placement response represents the state after B | 5 XYZ filled; 5 XYZ still working |
| D | Trade 103 later buys the remaining 5 XYZ at 25.20 | 10 XYZ for 251.30 USDT |
| E | Final matching order update is observed | FILLED, cumulative 10 XYZ |
Now hold moment C fixed and compare the three response choices. These are alternative representations of the same assumed snapshot, not three submissions or a guarantee about live response timing.
With ACK, the client receives the identity and time fields. It cannot derive zero executed quantity from their silence. With RESULT, the client can observe PARTIALLY_FILLED and decimal-string fields corresponding to origQty="10", executedQty="5" and cummulativeQuoteQty="125.30". With FULL, it additionally receives the two represented fills: 2 at 25.00 and 3 at 25.10. Binance's official new-order response examples show the state fields and the additional per-fill price, quantity, commission, commission asset and trade ID fields.
The arithmetic at C is:
2 × 25.00 + 3 × 25.10 = 125.30 USDT
125.30 ÷ 5 = 25.06 USDT per XYZ
At E, the additional gross cost is 5 × 25.20 = 126.00 USDT. Final gross cost is 251.30 USDT and the gross average price is 25.13 USDT per XYZ. A FULL response from C cannot contain the later trade from D. A RESULT response from C still supplies useful cumulative execution evidence despite omitting individual fill details.
The partial-fill management guide covers the separate problem of managing the acquired inventory and remaining instruction. Here, the point is narrower: response verbosity must not decide either quantity.
Merge placement responses and events into one record
The placement reply and account stream are observations of the same order. They should update one record keyed by the correctly scoped identity: venue, account, environment, product, symbol and exchange order ID, linked to the original client intent.
Binance's user data stream reports order updates through executionReport. It distinguishes current execution type from current order status, last executed quantity from cumulative filled quantity, and last quote quantity from cumulative quote quantity. It also includes trade and commission fields. Binance execution-report fields.
Suppose an adapter processes moment E's event before a delayed placement response from C. Blindly replacing the stored order with that response would move the local record from 10 filled back to five. Instead, preserve both observations and apply a documented merge policy that respects identity, event meaning and chronology. Flag contradictions for reconciliation rather than silently selecting whichever object arrived last.
Do not add cumulative totals across observations. Five from the placement response plus ten from the final event is not 15 XYZ purchased. Nor should trade 101 be booked again when it appears in a subsequent history read. Deduplicate actual fills by the venue's scoped trade identity and compare their sum with cumulative order quantities.
Chronology also requires explicit units. An integer transaction time and a locally recorded receipt time can use different scales or describe different events. The guide to exchange API timestamp units explains that contract; a larger raw integer alone is not a safe freshness rule.
Validate the selected shape before advancing a workflow
A useful placement decoder returns separate facts: acceptance evidence, available order state, available fill details and unresolved requirements. It should not manufacture missing facts to fit a universal order object.
For ACK, preserve execution state as unobserved until another authoritative observation supplies it. For RESULT, parse the documented state fields while preserving that individual trade details were not included. For FULL, validate the fill entries and their relationship to the response snapshot. A malformed or unexpectedly missing required field is a contract problem; do not replace it with zero. An empty array describes the represented fills; it is not a permanent promise that the order will never execute.
Use decimal arithmetic for price-times-quantity checks, and retain the raw provider field names when diagnosing mismatches. Binance spells its cumulative quote field cummulativeQuoteQty; normalizing that name internally must not make the decoder look for a differently spelled wire field. Preserve commission asset distinctions instead of deducting every commission from the quote balance.
Acceptance is also venue-specific. Bybit's create-order documentation says its acknowledgement confirms successful acceptance and directs clients to WebSocket status confirmation because placement is asynchronous. It does not expose Binance's three labels as a shared completion standard. Bybit's placement acknowledgement contract.
If the placement response is missing or unusable, selecting FULL beforehand does not resolve the uncertainty. Keep that investigation in the established order-timeout reconciliation process. Response preference is not a substitute for evidence about the original order.
Choose the response you can actually consume
ACK fits an integration that obtains order state elsewhere and keeps dependent work pending until that evidence arrives. RESULT fits a consumer that needs immediate state and cumulative totals but obtains detailed executions through another supported path. FULL fits a consumer that can ingest the returned trade details without treating them as the order's complete future history.
These choices are design tradeoffs, not measured latency promises. Do not claim a particular speed improvement without an appropriate measurement. Whichever mode is chosen, keep the ongoing observation and reconciliation path intact.
Validate with fixtures for ACK without quantities, RESULT without fills, FULL with a working remainder, a completed RESULT, a later event arriving before its placement reply, and a trade repeated across response and history. Each should produce the same final order and fill ledger for the same underlying execution sequence. Add those cases to the exchange API contract-test process when defaults or field shapes change.
Audit one downstream action next: identify the exact order status, quantity and fill evidence it requires. Then verify that receiving ACK, RESULT or FULL alone cannot bypass that requirement. That check turns a response-format choice into an explicit, reviewable execution boundary.