Orders

Everything about placing, tracking and cancelling orders. All write operations here require a trade-tier key, and every mutating call should carry an X-Idempotency-Key — a duplicated order is the most expensive bug in trading automation.

Your first order

A limit buy of 0.001 BTC at 60 000 USDT on Binance Spot, with the reference client:

// JavaScript
const { data: order } = await lexx.request("POST", "/orders", {
  body: {
    exchange: "binance-spot", symbol: "BTCUSDT",
    side: "BUY", type: "LIMIT",
    quantity: "0.001", price: "60000.00",
    timeInForce: "GTC", marketType: "spot",
  },
  headers: { "X-Idempotency-Key": crypto.randomUUID() },
});
console.log(order.id, order.status);

# Python
order = lexx.request("POST", "/orders", body={
    "exchange": "binance-spot", "symbol": "BTCUSDT",
    "side": "BUY", "type": "LIMIT",
    "quantity": "0.001", "price": "60000.00",
    "timeInForce": "GTC", "marketType": "spot",
}, headers={"X-Idempotency-Key": str(uuid.uuid4())})["data"]

The response data is a PublicOrder. Note that every amount is a string (why).

Order types

📌 Trailing stops are not a separate type. Send STOP_MARKET with trailingDelta (in basis points, 100 = 1%) and optionally activationPrice; the platform maps it to a trailing order downstream. In responses the order keeps type: "STOP_MARKET" with a populated trailing object.

The cookbook

Eight verified request bodies for POST /v2/orders — copy, adjust, send.

1 — Spot market buy for a fixed amount of quote currency (spend exactly 100 USDT):

{ "exchange": "binance-spot", "symbol": "SOLUSDT", "side": "BUY",
  "type": "MARKET", "quoteOrderQty": "100", "marketType": "spot" }

2 — Spot limit buy (0.5 SOL at 150):

{ "exchange": "binance-spot", "symbol": "SOLUSDT", "side": "BUY",
  "type": "LIMIT", "quantity": "0.5", "price": "150.00",
  "timeInForce": "GTC", "marketType": "spot" }

3 — Futures market long in hedge mode:

{ "exchange": "binance-futures", "symbol": "SOLUSDT", "side": "BUY",
  "type": "MARKET", "quantity": "1", "positionSide": "LONG", "marketType": "futures" }

4 — Futures limit short:

{ "exchange": "binance-futures", "symbol": "ETHUSDT", "side": "SELL",
  "type": "LIMIT", "quantity": "0.1", "price": "4000.00",
  "timeInForce": "GTC", "positionSide": "SHORT", "marketType": "futures" }

5 — Stop-loss on a long (market-sell if SOL drops to 140; reduceOnly guarantees it can only close, never flip, the position):

{ "exchange": "binance-futures", "symbol": "SOLUSDT", "side": "SELL",
  "type": "STOP_MARKET", "quantity": "1", "stopPrice": "140.00",
  "positionSide": "LONG", "reduceOnly": true,
  "workingType": "CONTRACT_PRICE", "marketType": "futures" }

6 — Take-profit on a long (market-sell when SOL reaches 200):

{ "exchange": "binance-futures", "symbol": "SOLUSDT", "side": "SELL",
  "type": "TAKE_PROFIT_MARKET", "quantity": "1", "stopPrice": "200.00",
  "positionSide": "LONG", "reduceOnly": true,
  "workingType": "CONTRACT_PRICE", "marketType": "futures" }

7 — Trailing stop, 2% callback (activates at 70 000, then follows the price up; fires on a 2% pullback from the peak):

{ "exchange": "binance-futures", "symbol": "BTCUSDT", "side": "SELL",
  "type": "STOP_MARKET", "quantity": "0.01",
  "activationPrice": "70000.00", "trailingDelta": 200,
  "positionSide": "LONG", "reduceOnly": true, "marketType": "futures" }

8 — Close the entire position (closePosition ignores quantity):

{ "exchange": "binance-futures", "symbol": "SOLUSDT", "side": "SELL",
  "type": "MARKET", "quantity": "0", "positionSide": "LONG",
  "closePosition": true, "marketType": "futures" }

Understanding the order object

{
  "id": "x-MZ8FjHFm-CEhAIco_dvygqmP",
  "exchange": "binance-futures", "symbol": "SOLUSDT",
  "side": "BUY", "type": "TAKE_PROFIT_LIMIT", "status": "OPENED",
  "positionSide": "LONG",
  "price": "50.94", "stopPrice": "57.57",
  "origQty": "2.26", "executedQty": "0", "fillPrice": null,
  "reduceOnly": false, "closePosition": false,
  "isContract": false, "isWorking": false,
  "creator": "BOT", "creatorId": "dvygqmP",
  "metadata": "{\"allocation\":{\"id\":\"jUBt3kx\",\"status\":\"SUCCESS\"}}",
  "specific": { "goodTillDate": 0 },
  "orderTime": 1782312970353
}

Real-time status changes arrive on the orders WebSocket channel — ORDER_CREATE once, then ORDER_UPDATE for every change including fills and cancellations.

Listing open orders — GET /orders

Served from an in-memory cache (no database round-trip):

The endpoint is intentionally not paginated. There is no “all historical orders” endpoint: anything older than the ~1-hour cache window is available as fills via GET /orders/trades, not as orders.

Cancelling — DELETE /orders/{id}

DELETE /v2/orders/x-MZ8FjHFm-CEhAIco_dvygqmP?exchange=binance-futures

• exchange is a required query parameter — and remember the query string is part of the signature.
• Cancelling an order that is already filled or cancelled is normally an idempotent no-op: the platform detects the state and returns 200 with the current order. A genuine exchange rejection is passed through (typically 400 INVALID_REQUEST with the exchange’s message).
• Alternative form: the ID may be supplied as an order query/body parameter instead of the path segment (DELETE /orders?exchange=…&order=…). Prefer the path form.
• Generous rate limit: 50 / 5 s — cancel storms are expected in trading.

Splitting — POST /orders/{id}/split

Turns one resting limit order into several at different prices: the original is cancelled and new orders are created (with new IDs — update your bookkeeping):

{ "exchange": "binance-futures", "prices": ["148.00", "146.00", "144.00"] }

• 2 to 50 price levels; the original quantity is divided equally among them.
• Response data is the array of newly created orders.

Fill history — GET /orders/trades

Per-execution history straight from the exchange. Both exchange and symbol are required; window with startTime/endTime (Unix ms) and limit (1–500, default 100):

{
  "symbol": "BTCUSDT", "side": "BUY",
  "price": "67432.50", "qty": "0.005",
  "comm": "0.01685812", "commAsset": "USDT",
  "buyer": true, "rPnl": null, "posSide": "BOTH",
  "time": 1719149400123
}

rPnl is the realized PnL of a position-closing futures fill — null for spot trades and position-opening fills. One order may produce many fills; aggregate by your order flow.

Field reference — CreateOrderRequest

✳ — required.

Good habits

• Exits with reduceOnly: true. Stop-losses and take-profits can then never accidentally open a position in the other direction.
• Hedge mode means positionSide everywhere. After enabling hedge mode, every futures order must state LONG or SHORT.
• Watch the risk shields. A key with allowedExchanges shields gets 403 on violations — by design.
• One order = one idempotency key, retries re-sign — the full pattern is in Idempotency.

_{Verified against API spec v2.0.0 · 2026-07-11}