Orders API Reference
12 endpoints for the complete order lifecycle: place, cancel, mark paid, release coin, and history. Two endpoints use adaptive auth patterns and one uses a three-fallback chain for environment compatibility.
EP-13: Adaptive Auth Pattern
getUserOrderDetail attempts authentication in two stages to minimise signature overhead:
- Attempt 1 — unsigned: POST with
X-MBX-APIKEYheader only (no HMAC) - On 401 / 403: retry with full HMAC-SHA256 signature (after time sync if
-1021/-1022)
EP-16: Three-Fallback Chain
listUserOrderHistory uses a three-stage fallback because Binance behaves differently across environments and API versions:
1.GET with
startTimestamp / endTimestamp2.GET with
startTime / endTime (alias param names)3.POST with same params (some environments reject GET for this endpoint)
Naming: adsNo (not advNo) in EP-11 and EP-18
Two order endpoints use adsNo to reference an ad, while the Ads controller uses advNo. The inconsistency is from Binance — using the wrong field name silently returns an error.
checkIfCanPlaceOrder(EP-11) → usesadsNoplaceOrder(EP-18) → usesadsNo- All Ads controller endpoints → use
advNo/advNos