binance_place_twap_order
Place a spot TWAP algo order on Binance to split a large trade into smaller sub-orders over a set duration, reducing price impact versus one market order.
Instructions
Place a REAL spot TWAP algo order on Binance. This spends real money.
Calls POST /sapi/v1/algo/spot/newOrderTwap (SIGNED, UID weight 3000 of a
180,000/min budget — call it sparingly). Binance splits quantity into sub-orders and
works them over duration seconds, aiming at the time-weighted average price instead
of taking the book in one hit.
Kill-switch. This call is refused with Error: … trading is disabled … unless the
server runs with BINANCE_ALLOW_TRADING=1. The gate lives in the HTTP client, so no
tool can bypass it. If you see that error, the operator has deliberately put the
server in read-only mode — report it, do not try to work around it.
Binance's own constraints, all rejected server-side if broken:
duration300-86400 seconds (5 minutes to 24 hours) — checked locally too.Minimum notional ≈ 1,000 USDT equivalent per algo order (the docs also quote a per-symbol maximum of 200k / 2mm / 10mm; let the API arbitrate the ceiling).
At most 20 open algo orders at a time — check with
binance_get_open_algo_ordersbefore adding another.client_algo_id, when supplied, must be exactly 32 characters.
success: true means ACCEPTED, NOT EXECUTED. The response carries no fill
information at all; it only says Binance took the order. What actually traded is
visible through binance_get_open_algo_orders, binance_get_algo_order_history and
binance_get_algo_sub_orders.
When to Use:
Working a position that is large relative to the book, where a single MARKET order would move the price against you.
Spreading an entry or exit over minutes or hours on purpose.
When NOT to Use:
For an ordinary immediate or resting order — use
binance_place_order(spot_orders.py); it is weight 1, not 3000, and has no notional floor.Below ~1,000 USDT of notional — the API rejects it; place a normal order instead.
For USDⓈ-M / COIN-M futures TWAP or VP — that is a different product on a different wallet and this server does not implement it.
Returns:
A confirmation echoing exactly the four fields Binance returned — clientAlgoId,
success, code, msg — plus an explicit note that the order is accepted and not
executed, and which tool to poll. A success: false body (Binance answers those with
HTTP 200) is rendered as Error: <msg> (code <code>), never as a confirmation.
Examples: params = {"symbol": "BTCUSDT", "side": "BUY", "quantity": "0.5", "duration": 3600} params = {"symbol": "BTCUSDT", "side": "SELL", "quantity": "1.25", "duration": 7200, "limit_price": "65000.00", "client_algo_id": "abcdefghijklmnopqrstuvwxyz012345"}
Error Handling:
Error: … trading is disabled …→ the kill-switch is off; nothing was sent.A duration outside 300-86400 or a 31-character
client_algo_idfails locally, before anything is signed.-2010 / -1013 point at balance, the notional floor or a symbol filter; -2015 means the key lacks Spot & Margin Trading permission or this IP is not allowlisted.
A 5xx or a timeout means the execution status is UNKNOWN — the algo order may well be live. Check
binance_get_open_algo_orders(andbinance_get_algo_order_history) before doing anything else. NEVER resend blindly: a duplicate TWAP is a second position, and each one eats one of the 20 slots.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| params | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |