Binance Connector JS
    Preparing search index...

    Class TradeApi

    TradeApi - object-oriented interface TradeApi

    Implements

    Index

    Constructors

    constructor

    Methods

    deleteOpenOrders deleteOrder deleteOrderList newOrder orderAmendKeepPriority orderCancelReplace orderListOco orderListOpo orderListOpoco orderListOto orderListOtoco orderOco orderTest sorOrder sorOrderTest

    Constructors

    Methods

    • Cancel an active order.

      Weight(IP): 1

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      • Either orderId or origClientOrderId must be sent.
      • If both orderId and origClientOrderId are provided, the orderId is searched first, then the origClientOrderId from that result is checked against that order. If both conditions are not met the request will be rejected.
      • The performance for canceling an order (single cancel or as part of a cancel-replace) is always better when only orderId is sent. Sending origClientOrderId or both orderId + origClientOrderId will be slower.

      Parameters

      Returns Promise<RestApiResponse<DeleteOrderResponse>>

      TradeApi

      Binance API Documentation

    • Send in a new order.

      This adds 1 order to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.

      Weight(IP): 1

      Unfilled Order Count: 1

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Some additional mandatory parameters based on order type:

      Type Additional mandatory parameters Additional Information
      LIMIT timeInForce, quantity, price
      MARKET quantity or quoteOrderQty MARKET orders using the quantity field specifies the amount of the base asset the user wants to buy or sell at the market price.
      E.g. MARKET order on BTCUSDT will specify how much BTC the user is buying or selling.

      MARKET orders using quoteOrderQty specifies the amount the user wants to spend (when buying) or receive (when selling) the quote asset; the correct quantity will be determined based on the market liquidity and quoteOrderQty.
      E.g. Using the symbol BTCUSDT:
      BUY side, the order will buy as many BTC as quoteOrderQty USDT can.
      SELL side, the order will sell as much BTC needed to receive quoteOrderQty USDT.
      STOP_LOSS quantity, stopPrice or trailingDelta This will execute a MARKET order when the conditions are met. (e.g. stopPrice is met or trailingDelta is activated)
      STOP_LOSS_LIMIT timeInForce, quantity, price, stopPrice or trailingDelta
      TAKE_PROFIT quantity, stopPrice or trailingDelta This will execute a MARKET order when the conditions are met. (e.g. stopPrice is met or trailingDelta is activated)
      TAKE_PROFIT_LIMIT timeInForce, quantity, price, stopPrice or trailingDelta
      LIMIT_MAKER quantity, price This is a LIMIT order that will be rejected if the order immediately matches and trades as a taker.
      This is also known as a POST-ONLY order.

      Notes on using parameters for Pegged Orders: These parameters are allowed for LIMIT, LIMIT_MAKER, STOP_LOSS_LIMIT, TAKE_PROFIT_LIMIT orders. If pegPriceType is specified, price becomes optional. Otherwise, it is still mandatory. pegPriceType=PRIMARY_PEG means the primary peg, that is the best price on the same side of the order book as your order. pegPriceType=MARKET_PEG means the market peg, that is the best price on the opposite side of the order book from your order. Use pegOffsetType and pegOffsetValue to request a price level other than the best one. These parameters must be specified together.

      Other info: Any LIMIT or LIMIT_MAKER type order can be made an iceberg order by sending an icebergQty. Any order with an icebergQty MUST have timeInForce set to GTC. For STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT_LIMIT and TAKE_PROFIT orders, trailingDelta can be combined with stopPrice. MARKET orders using quoteOrderQty will not break LOT_SIZE filter rules; the order will execute a quantity that will have the notional value as close as possible to quoteOrderQty. Trigger order price rules against market price for both MARKET and LIMIT versions: Price above market price: STOP_LOSS BUY, TAKE_PROFIT SELL Price below market price: STOP_LOSS SELL, TAKE_PROFIT BUY

      Parameters

      Returns Promise<RestApiResponse<SpotRestAPI.NewOrderResponse>>

      TradeApi

      Binance API Documentation

      • Cancels an existing order and places a new order on the same symbol.
      • Filters and Order Count are evaluated before the processing of the cancellation and order placement occurs.
      • A new order that was not attempted (i.e. when newOrderResult: NOT_ATTEMPTED), will still increase the unfilled order count by 1.
      • You can only cancel an individual order from an orderList using this endpoint, but the result is the same as canceling the entire orderList.

      Weight(IP): 1

      Unfilled Order Count: 1

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Similar to POST /api/v3/order, additional mandatory parameters are determined by type. Response format varies depending on whether the processing of the message succeeded, partially succeeded, or failed.

      Request Response
      cancelReplaceMode orderRateLimitExceededMode Unfilled Order Count cancelResult newOrderResult status
      STOP_ON_FAILURE DO_NOTHING Within Limits ✅ SUCCESS ✅ SUCCESS 200
      ❌ FAILURE ➖ NOT_ATTEMPTED 400
      ✅ SUCCESS ❌ FAILURE 409
      Exceeds Limits ✅ SUCCESS ✅ SUCCESS N/A
      ❌ FAILURE ➖ NOT_ATTEMPTED N/A
      ✅ SUCCESS ❌ FAILURE N/A
      CANCEL_ONLY Within Limits ✅ SUCCESS ✅ SUCCESS 200
      ❌ FAILURE ➖ NOT_ATTEMPTED 400
      ✅ SUCCESS ❌ FAILURE 409
      Exceeds Limits ❌ FAILURE ➖ NOT_ATTEMPTED 429
      ✅ SUCCESS ❌ FAILURE 429
      ALLOW_FAILURE DO_NOTHING Within Limits ✅ SUCCESS ✅ SUCCESS 200
      ❌ FAILURE ❌ FAILURE 400
      ❌ FAILURE ✅ SUCCESS 409
      ✅ SUCCESS ❌ FAILURE 409
      Exceeds Limits ✅ SUCCESS ✅ SUCCESS N/A
      ❌ FAILURE ❌ FAILURE N/A
      ❌ FAILURE ✅ SUCCESS N/A
      ✅ SUCCESS ❌ FAILURE N/A
      CANCEL_ONLY Within Limits ✅ SUCCESS ✅ SUCCESS 200
      ❌ FAILURE ❌ FAILURE 400
      ❌ FAILURE ✅ SUCCESS 409
      ✅ SUCCESS ❌ FAILURE 409
      Exceeds Limits ✅ SUCCESS ✅ SUCCESS N/A
      ❌ FAILURE ❌ FAILURE 400
      ❌ FAILURE ✅ SUCCESS N/A
      ✅ SUCCESS ❌ FAILURE 409

      Notes:*

      • The performance for canceling an order (single cancel or as part of a cancel-replace) is always better when only orderId is sent. Sending origClientOrderId or both orderId + origClientOrderId will be slower.

      Parameters

      Returns Promise<RestApiResponse<SpotRestAPI.OrderCancelReplaceResponse>>

      TradeApi

      Binance API Documentation

    • Send in an one-cancels-the-other (OCO) pair, where activation of one order immediately cancels the other.

      • An OCO has 2 orders called the above order and below order.
      • One of the orders must be a LIMIT_MAKER/TAKE_PROFIT/TAKE_PROFIT_LIMIT order and the other must be STOP_LOSS or STOP_LOSS_LIMIT order.
      • Price restrictions
      • If the OCO is on the SELL side:
      • LIMIT_MAKER/TAKE_PROFIT_LIMIT price > Last Traded Price > STOP_LOSS/STOP_LOSS_LIMIT stopPrice
      • TAKE_PROFIT stopPrice > Last Traded Price > STOP_LOSS/STOP_LOSS_LIMIT stopPrice
      • If the OCO is on the BUY side:
      • LIMIT_MAKER/TAKE_PROFIT_LIMIT price < Last Traded Price < stopPrice
      • TAKE_PROFIT stopPrice < Last Traded Price < STOP_LOSS/STOP_LOSS_LIMIT stopPrice * OCOs add 2 orders to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.
      • OCOs add 2 orders to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.

      Weight(IP): 1

      Unfilled Order Count: 2

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Parameters

      Returns Promise<RestApiResponse<OrderListOcoResponse>>

      TradeApi

      Binance API Documentation

    • Place an OTO.

      • An OTO (One-Triggers-the-Other) is an order list comprised of 2 orders.
      • The first order is called the working order and must be LIMIT or LIMIT_MAKER. Initially, only the working order goes on the order book.
      • The second order is called the pending order. It can be any order type except for MARKET orders using parameter quoteOrderQty. The pending order is only placed on the order book when the working order gets fully filled.
      • If either the working order or the pending order is cancelled individually, the other order in the order list will also be canceled or expired.
      • When the order list is placed, if the working order gets immediately fully filled, the placement response will show the working order as FILLED but the pending order will still appear as PENDING_NEW. You need to query the status of the pending order again to see its updated status.
      • OTOs add 2 orders to the EXCHANGE_MAX_NUM_ORDERS filter and MAX_NUM_ORDERS filter.

      Weight(IP): 1

      Unfilled Order Count: 2

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Mandatory parameters based on pendingType or workingType*

      Depending on the pendingType or workingType, some optional parameters will become mandatory.

      Type Additional mandatory parameters Additional information
      workingType = LIMIT workingTimeInForce
      pendingType = LIMIT pendingPrice, pendingTimeInForce
      pendingType = STOP_LOSS or TAKE_PROFIT pendingStopPrice and/or pendingTrailingDelta
      pendingType = STOP_LOSS_LIMIT or TAKE_PROFIT_LIMIT pendingPrice, pendingStopPrice and/or pendingTrailingDelta, pendingTimeInForce

      Parameters

      Returns Promise<RestApiResponse<OrderListOtoResponse>>

      TradeApi

      Binance API Documentation

    • Place an OTOCO.

      • An OTOCO (One-Triggers-One-Cancels-the-Other) is an order list comprised of 3 orders.
      • The first order is called the working order and must be LIMIT or LIMIT_MAKER. Initially, only the working order goes on the order book.
      • The behavior of the working order is the same as the OTO.
      • OTOCO has 2 pending orders (pending above and pending below), forming an OCO pair. The pending orders are only placed on the order book when the working order gets fully filled.
      • The rules of the pending above and pending below follow the same rules as the Order list OCO.
      • OTOCOs add 3 orders to the EXCHANGE_MAX_NUM_ORDERS filter and MAX_NUM_ORDERS filter.

      Weight(IP): 1

      Unfilled Order Count: 3

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Mandatory parameters based on pendingAboveType, pendingBelowType or workingType*

      Depending on the pendingAboveType/pendingBelowType or workingType, some optional parameters will become mandatory.

      Type Additional mandatory parameters Additional information
      workingType = LIMIT workingTimeInForce
      pendingAboveType= LIMIT_MAKER pendingAbovePrice
      pendingAboveType = STOP_LOSS/TAKE_PROFIT pendingAboveStopPrice and/or pendingAboveTrailingDelta
      pendingAboveType=STOP_LOSS_LIMIT/TAKE_PROFIT_LIMIT pendingAbovePrice, pendingAboveStopPrice and/or pendingAboveTrailingDelta, pendingAboveTimeInForce
      pendingBelowType= LIMIT_MAKER pendingBelowPrice
      pendingBelowType= STOP_LOSS/TAKE_PROFIT pendingBelowStopPrice and/or pendingBelowTrailingDelta
      pendingBelowType=STOP_LOSS_LIMIT/TAKE_PROFIT_LIMIT pendingBelowPrice, pendingBelowStopPrice and/or pendingBelowTrailingDelta, pendingBelowTimeInForce

      Parameters

      Returns Promise<RestApiResponse<OrderListOtocoResponse>>

      TradeApi

      Binance API Documentation

    Settings

    Member Visibility

    On This Page

    Constructors
    Methods