An exchange API HTTP 200 response does not by itself prove that a trading request succeeded. Read the documented application code and endpoint-specific result inside the response, validate its shape and identity, and distinguish an accepted request from a completed order. Missing, malformed or unfamiliar results remain unresolved; they do not establish that no trade occurred.
The mistake often starts with a reasonable-looking rule: if the HTTP client reports success, show a green check. That rule can hide an explicit exchange rejection. Its opposite, treating every HTTP error as proof that an order failed, can also create unwanted repeat submissions.
Read four separate results
HTTP status, response validity, business acceptance and order execution answer different questions. Keep each observation rather than collapsing them into one boolean.
| Check | What it establishes | What it cannot establish alone |
|---|---|---|
| HTTP status | The server's HTTP-level result | Whether the business operation was accepted |
| Response contract | The body has the expected structure, types and matching identity | Whether its business code means success |
| Application result | The endpoint reports a documented outcome for this operation | Whether an accepted order has filled |
| Order evidence | An identified order's observed state and executions | That every later event has already arrived |
HTTP 200 is defined as a successful request, with response content interpreted according to the method. For POST, that content can report the action's status or results. An exchange's API contract supplies the business meaning of that report; HTTP does not define its trading-error fields. See RFC 9110's HTTP 200 semantics.
For a private account read, success requires the documented result for the intended account and environment. For order creation, it requires the relevant acceptance evidence. For a cancellation, it must be interpreted under that endpoint's contract. Reusing one success condition across all three loses those differences.
Recognize the exchange's envelope
OKX's error table explicitly pairs HTTP 200 with application code 1 for a failed operation and 2 for partial bulk success. It also lists order amount and price-limit errors under HTTP 200. Its single-order response defines top-level code and an operation result inside data, including sCode; the documented success value for these fields is the string "0". See the OKX V5 response and error reference.
Bybit uses a different envelope. Its common response has numeric retCode, a message, result and other fields. Its error reference defines 0 as successful and distinguishes parameter, timestamp, signature and permission failures. An adapter should interpret the relevant numeric code rather than guess from whether the message contains the English word “success.” See Bybit's common response fields and Bybit's error-code definitions.
Those conventions are scoped to the documented APIs. Do not infer that every exchange uses zero, the same field name or the same JSON type. A JavaScript truthiness check treats string "0" differently from numeric 0; a missing property can also pass a careless “not an error” condition. Validate presence and type before comparing the documented value. If an adapter normalizes types, make the accepted input forms explicit instead of accepting arbitrary coercions.
Preserve the provider code, sub-code where supplied and redacted message. A normalized category such as “authentication failure” is useful for routing, but it should not erase the evidence needed to identify the specific cause.
Five requests that defeat one green check
The following is an original hypothetical adapter exercise with five separate create-order attempts. It is not a batch, captured traffic or a live-account test. Only selected observations are shown; the malformed rows are deliberately constructed failure fixtures.
| Attempt | HTTP result | Preserved response observation | Classification |
|---|---|---|---|
| A | 200 | Valid OKX-shaped body; code="0", sole sCode="0", matching client and order identity | Accepted acknowledgement; execution still needs confirmation |
| B | 200 | Valid body; code="1", sole sCode="51005", matching request and amount-limit rejection | Explicit rejection of this create attempt |
| C | 200 | Parsed JSON has a message but no required application code or expected result | Unusable contract; submitted attempt unresolved |
| D | 200 | An HTML gateway page arrives where this endpoint requires JSON | Unusable response; submitted attempt unresolved |
| E | 400 | Documented OKX timeout code 50004 | Outcome unknown; recover the original attempt |
The venue reference specifically says that 50004 does not determine success or failure and calls for checking the request result. This is why even a 4xx response cannot universally mean “safe to send a new order.” OKX timeout and error definitions.
A dashboard that counts HTTP 200 reports four successes out of five, or 80%. This fixture instead contains one accepted acknowledgement, one explicit rejection and three unresolved submissions: 20%, 20% and 60% of the five attempts. These percentages describe invented test cases, not an exchange reliability measurement. None of the five rows supplies confirmed fill evidence.
For C and D, log the parsing or contract failure separately from the order's unknown outcome. Calling the parser failure a trade rejection would add a conclusion the response never established. For E, retain the original identity and use the order-timeout reconciliation process before considering another write.
Specify success before implementing retries
For each endpoint, write a short acceptance record:
- Identify the venue, API version, account, environment, product, method and path.
- List expected HTTP outcomes, body format, required fields and documented field types.
- State the exact business acceptance predicate and any nested operation result required by that endpoint.
- State which identity binds the result to the original request, and what evidence establishes completion.
- Define handling for explicit rejection, documented uncertainty and unusable or unfamiliar responses.
A successful placement acknowledgement is a useful milestone, but the next step remains specific. Bybit describes placement as asynchronous and directs clients to its WebSocket stream to confirm order status. Its acknowledgement is not evidence that the requested quantity has executed. Bybit's placement acknowledgement contract.
Keep retry eligibility separate from classification. A documented parameter rejection can lead to a corrected, newly assessed request. A timeout needs reconciliation. An unrecognized application code needs investigation rather than a default success branch. Preserve unresolved attempts across restarts so a later worker cannot mistake missing local completion for permission to trade again. The idempotency guide covers that durable intent boundary.
For batches, the acceptance record must extend to each operation. The bulk-order partial-success guide explains item mapping and selective recovery; a top-level envelope cannot substitute for those results.
Test boundaries without sending more trades
Replay the five fixtures through a controlled adapter test. Remove a required code, change its type, substitute an unfamiliar value, return an unexpected result shape and mismatch the client identity. The expected behavior is a visible contract or business outcome with the original attempt preserved. Do not turn a missing order record into a manufactured success object to keep downstream code running.
Signing and decoding are adjacent boundaries with different evidence. When an explicit application rejection points to authentication, inspect the URL-encoding and signature byte rules rather than changing response handling. When binary WebSocket content cannot be interpreted, use the compression and decoding guide; an undecoded frame supplies no application acknowledgement.
An operational record should retain observation time, endpoint, non-secret request reference, HTTP status, parsing result, raw application code and classified outcome. Redact credentials, signatures and private account content before sharing diagnostics. Keep a separate field for order state so “request accepted” cannot quietly become “filled.”
Editorial method: Prepared with AI assistance from primary documentation reviewed on 23 October 2026. The classification worksheet and five-request fixture are original educational constructions. No live requests, exchange reliability measurement or KLINEO adapter verification was performed; venue response contracts do not establish KLINEO feature support.