Order status and history

Endpoints

Quote.Trade /api/v2 is the Binance-v3-compatible API for all regular order flow. Quote.Trade /api/v3 is reserved for advanced and prompt-order support; it is not the version to use for regular trading.

These GET routes cannot place or cancel an order. Placement and cancellation keep their existing endpoints. API-managed parent lists remain on the managed-order list API; native child executions may also appear in native history. Do not count parent size and child fills as separate trades.

Authentication

Use X-MBX-APIKEY and a signed query, with timestamp in Unix milliseconds. HMAC-SHA256 signs the exact URL-encoded query bytes before the signature parameter is appended. A signature header is also accepted. If both are supplied they must agree.

recvWindow defaults to 5000 milliseconds, must be greater than zero and no more than 60000, and accepts up to three fractional digits. Requests 1000 milliseconds or more ahead of server time or older than the receive window are rejected. These V2 GET queries use timestamp validation; the existing POST endpoints retain their nonce rules.

API keys require active READ permission. User/account ownership or an existing on-behalf entitlement and IP restrictions are checked before any lookup. A known order ID never grants access to another account.

GET /api/v2/order?symbol=BTC%2FUSD&origClientOrderId=my-btc-limit&timestamp=REPLACE_WITH_CURRENT_MS&signature=HMAC_HEX
X-MBX-APIKEY: YOUR_API_KEY

Use the exact symbol returned by the deployment's exchangeInfo catalog. A Quote.Trade USD instrument is not automatically the same product as Binance BTCUSDT spot.

Order status

Supply symbol and either orderId or origClientOrderId. The aliases clientOrderId, clOrdId and clordid are accepted. Query client IDs must be nonempty and at most 64 characters; managed-order creation has a separate 36-character limit. Conflicting client-ID aliases are rejected. If both numeric and client IDs are present, both must match the same order. IDs remain 64-bit integers; do not round them through JavaScript floating-point values.

Native lookup checks current and archived orders, then persisted execution reports on a cache miss. Client IDs are case-sensitive. On a cache hit, reused client IDs resolve among cached matching records; persistence is consulted only on a cache miss. Do not reuse client IDs across logical orders or assume a global latest-across-cache-and-database lookup. Use the returned orderId to disambiguate. API-managed parent IDs use the existing negative-ID namespace.

{
  "symbol": "BTC/USD", "orderId": 12345, "orderListId": -1,
  "clientOrderId": "my-btc-limit", "clOrdId": "my-btc-limit",
  "status": "CANCELED", "type": "LIMIT", "side": "BUY",
  "timeInForce": "FOK", "price": "66186.24", "origQty": "0.000302",
  "executedQty": "0.000000", "stopPrice": "0.00",
  "rejectReason": null, "reason": null, "errorMessage": null,
  "updateTime": 1792144800000, "isWorking": false,
  "accountId": 123, "isPaperTrade": false
}

Prices and quantities on the new V2 GET queries are decimal strings. A status is the latest known state, not a promise that a new order will fill. Unknown native orders return {"code":-2013,"msg":"Order does not exist"}. A negative managed-parent ID uses the managed lookup and its error contract; do not assume every missing parent returns -2013.

Bounded native order history

allOrders requires symbol. It returns one latest snapshot per native order, including NEW, PARTIALLY_FILLED, FILLED, CANCELED, EXPIRED and REJECTED when recorded. An empty successful query returns []. Database failures return an error, never an apparently empty history.

• limit: default 500; minimum 1; maximum 1000. Larger or invalid values are rejected.
• orderId: inclusive lower bound, not an exact-match filter on this list endpoint. For a forward scan of positive native IDs, start at orderId=1 and continue with the last returned orderId plus one. Starting without orderId selects the newest page; advancing from that page does not recover older orders. Rejections without an assigned ID are not covered by a positive-ID scan; query them by client ID while retained.
• Without orderId, the newest numeric order IDs are selected. The returned page is sorted by ascending orderId. This differs from the UI's newest-first managed-parent list.
• startTime and endTime: inclusive Unix milliseconds, filtering stored update/event time. This is a Quote.Trade difference from an exchange's order-creation-time filtering.
• Client-ID aliases can filter the native list. Use the single-order endpoint for an exact server-ID lookup.

Use GET /api/v3/openOrders with the documented managed-order history filters and cursor for API-managed parent history. Its existing pagination and response envelope are unchanged.

Canceled and rejected orders

Missing reasons are null. A canceled order is not necessarily an error. A failed cancellation request must not change the original order to REJECTED.

WebSocket queries

Connect to wss://app.quote.trade/ws/listenKey (or the configured environment host). Signed query messages authenticate independently and require no prior listen-key or requestToken subscription login. A key created in API Management belongs in params.apiKey; the legacy push subscription's requestToken is a separate account/wallet session token. Supply flat params with apiKey, timestamp and signature. For HMAC, sort all parameter names except signature alphabetically and join their decoded key=value pairs with & before signing.

{
  "id": "status-1", "method": "order.status",
  "params": {
    "apiKey": "YOUR_API_KEY", "symbol": "BTC/USD",
    "origClientOrderId": "my-btc-limit",
    "timestamp": 1792144800000, "signature": "REPLACE_WITH_SIGNATURE"
  }
}

Successful replies use {"id":"status-1","status":200,"result":{...},"rateLimits":[]}. History uses an array in result. Query errors use the same request id with an error object. Subscribe to private execution updates and reconcile after reconnect using the read-only queries; queries do not submit orders.

Existing status and event-history endpoints

POST /api/v2/orderStatus also accepts the alias POST /api/v2/getOrderStatus. It keeps its scaled-integer price/quantity fields and their scale fields. POST /api/v2/getOrderHistory keeps its {"orders":[...]} execution-event envelope and decimal-string fields. Existing POST signing and nonce conventions still apply. Current User.validateNonce accepts every value, so these POST calls do not gain the timestamp freshness checks of the new V2 GET queries; see the REST replay-protection limitation.

Both gain client-ID aliases and additive clientOrderId/status/rejectReason/reason/errorMessage fields. Event history returns at most the latest 1000 retained events in chronological order. For snapshot pagination use the new allOrders endpoint. A specific native history request no longer appends unrelated managed-parent orders. The older unversioned native API is not redefined by this page.

Compatibility and deployment

This adds Binance-style query names, signing, ID lookup, statuses and decimal-string values. It is not a claim of full Binance Spot API parity. Native order snapshots do not currently provide all Binance fields, such as original creation time, cumulative quote quantity and self-trade-prevention metadata. Quote.Trade instruments, FOK execution, managed negative parent IDs and request-rejection retention differ.

Regular placement uses POST /api/v2/order and regular cancellation uses DELETE /api/v2/order. These existing endpoints and their semantics remain unchanged. The new status and history GET routes belong to the same V2 API. The managed /api/v3/openOrders endpoint remains specific to API-managed parents. Managed snapshots have their own schema and do not currently return the native rejectReason/reason/errorMessage fields.

Deploy the updated API and documentation together. Preserve the versioned paths at the gateway: /api/v2/... must reach the V2 API handler, and /api/v3/... must reach the matching advanced-order or prompt servlet. Do not apply a legacy /api/ to /liquidityApi/ rewrite to these versioned paths. An empty HTTP 200 body is not a successful status/history result; verify routing and the deployed API build before interpreting it as an empty order list. The configured GET allowlist must permit orderStatus and allOrders; do not replace a restricted allowlist with a wildcard. If using the new POST alias, allow getOrderStatus for POST as well. Verify signed REST and WebSocket requests against a staging deployment with a read-only test account. Check PostgreSQL plans for account/symbol/order-ID and account/client-ID lookups on production-sized history.

Reference: Binance REST account queries, Binance WebSocket account queries and execution-report fields, reviewed October 16, 2026.