Binance Connector JS
    Preparing search index...

    Class TradeApi

    TradeApi - object-oriented interface TradeApi

    Implements

    Index

    Constructors

    constructor

    Methods

    openOrdersCancelAll orderAmendKeepPriority orderCancel orderCancelReplace orderListCancel orderListPlace orderListPlaceOco orderListPlaceOpo orderListPlaceOpoco orderListPlaceOto orderListPlaceOtoco orderPlace orderTest sorOrderPlace sorOrderTest

    Constructors

    Methods

    • Cancel an active order.

      Weight(IP): 1

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Notes:

      If both orderId and origClientOrderId parameters 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.

      newClientOrderId will replace clientOrderId of the canceled order, freeing it up for new orders.

      If you cancel an order that is a part of an order list, the entire order list is canceled.

      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<WebsocketApiResponse<OrderCancelResponse>>

      TradeApi

      Binance API Documentation

      • Cancel an existing order and immediately place a new order instead of the canceled one. 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 method, but the result is the same as canceling the entire orderList.not attempted (i.e. when newOrderResult: NOT_ATTEMPTED), will still increase the unfilled order count by 1.

      Weight(IP): 1

      Unfilled Order Count: 1

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Similar to the order.place request, additional mandatory parameters (*) are determined by the new order type.

      Available cancelReplaceMode options:

      STOP_ON_FAILURE – if cancellation request fails, new order placement will not be attempted. ALLOW_FAILURE – new order placement will be attempted even if the cancel request fails.

      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 200
      ❌ FAILURE ❌ FAILURE 400
      ❌ FAILURE ✅ SUCCESS N/A
      ✅ SUCCESS ❌ FAILURE 409

      Notes:

      If both cancelOrderId and cancelOrigClientOrderId parameters are provided, the cancelOrderId is searched first, then the cancelOrigClientOrderId from that result is checked against that order. If both conditions are not met the request will be rejected.

      cancelNewClientOrderId will replace clientOrderId of the canceled order, freeing it up for new orders.

      newClientOrderId specifies clientOrderId value for the placed order.

      A new order with the same clientOrderId is accepted only when the previous one is filled or expired.

      The new order can reuse old clientOrderId of the canceled order.

      This cancel-replace operation is not transactional.

      If one operation succeeds but the other one fails, the successful operation is still executed.

      For example, in STOP_ON_FAILURE mode, if the new order placement fails, the old order is still canceled.

      Filters and order count limits are evaluated before cancellation and order placement occurs.

      If new order placement is not attempted, your order count is still incremented.

      Like order.cancel, if you cancel an individual order from an order list, the entire order list is canceled.

      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<WebsocketApiResponse<SpotWebsocketAPI.OrderCancelReplaceResponse>>

      TradeApi

      Binance API Documentation

    • Send in a new one-cancels-the-other (OCO) pair: LIMIT_MAKER + STOP_LOSS/STOP_LOSS_LIMIT orders (called legs), where activation of one order immediately cancels the other.

      This adds 1 order to 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

      Notes:

      listClientOrderId parameter specifies listClientOrderId for the OCO pair.

      A new OCO with the same listClientOrderId is accepted only when the previous one is filled or completely expired.

      listClientOrderId is distinct from clientOrderId of individual orders.

      limitClientOrderId and stopClientOrderId specify clientOrderId values for both legs of the OCO.

      A new order with the same clientOrderId is accepted only when the previous one is filled or expired.

      Price restrictions on the legs:

      side Price relation
      BUY price < market price < stopPrice
      SELL price > market price > stopPrice

      Both legs have the same quantity.

      However, you can set different iceberg quantity for individual legs.

      If stopIcebergQty is used, stopLimitTimeInForce must be GTC.

      trailingDelta applies only to the STOP_LOSS/STOP_LOSS_LIMIT leg of the OCO.

      Parameters

      Returns Promise<WebsocketApiResponse<OrderListPlaceResponse>>

      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 price < Last Traded Price < STOP_LOSS/STOP_LOSS_LIMIT stopPrice TAKE_PROFIT stopPrice > Last Traded Price > STOP_LOSS/STOP_LOSS_LIMIT stopPrice OCOs add 2 orders to the EXCHANGE_MAX_ORDERS filter and MAX_NUM_ORDERS filter.

      Weight(IP): 1

      Unfilled Order Count: 2

      Security Type: TRADE

      Notes: Data Source:* Matching Engine

      Parameters

      Returns Promise<WebsocketApiResponse<OrderListPlaceOcoResponse>>

      TradeApi

      Binance API Documentation

    • Places 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<WebsocketApiResponse<OrderListPlaceOtoResponse>>

      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<WebsocketApiResponse<OrderListPlaceOtocoResponse>>

      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

      Certain parameters (*) become mandatory based on the order type:

      Order type Mandatory parameters
      LIMIT
      • timeInForce
      • price
      • quantity
      LIMIT_MAKER
      • price
      • quantity
      MARKET
      • quantity or quoteOrderQty
      STOP_LOSS
      • quantity
      • stopPrice or trailingDelta
      STOP_LOSS_LIMIT
      • timeInForce
      • price
      • quantity
      • stopPrice or trailingDelta
      TAKE_PROFIT
      • quantity
      • stopPrice or trailingDelta
      TAKE_PROFIT_LIMIT
      • timeInForce
      • price
      • quantity
      • stopPrice or trailingDelta

      Supported order types:

      Order type Description
      LIMIT

      Buy or sell quantity at the specified price or better.

      LIMIT_MAKER

      LIMIT order that will be rejected if it immediately matches and trades as a taker.

      This order type is also known as a POST-ONLY order.

      MARKET

      Buy or sell at the best available market price.

      • MARKET order with quantity parameter specifies the amount of the base asset you want to buy or sell. Actually executed quantity of the quote asset will be determined by available market liquidity.

        E.g., a MARKET BUY order on BTCUSDT for "quantity": "0.1000" specifies that you want to buy 0.1 BTC at the best available price. If there is not enough BTC at the best price, keep buying at the next best price, until either your order is filled, or you run out of USDT, or market runs out of BTC.

      • MARKET order with quoteOrderQty parameter specifies the amount of the quote asset you want to spend (when buying) or receive (when selling). Actually executed quantity of the base asset will be determined by available market liquidity.

        E.g., a MARKET BUY on BTCUSDT for "quoteOrderQty": "100.00" specifies that you want to buy as much BTC as you can for 100 USDT at the best available price. Similarly, a SELL order will sell as much available BTC as needed for you to receive 100 USDT (before commission).

      STOP_LOSS

      Execute a MARKET order for given quantity when specified conditions are met.

      I.e., when stopPrice is reached, or when trailingDelta is activated.

      STOP_LOSS_LIMIT

      Place a LIMIT order with given parameters when specified conditions are met.

      TAKE_PROFIT

      Like STOP_LOSS but activates when market price moves in the favorable direction.

      TAKE_PROFIT_LIMIT

      Like STOP_LOSS_LIMIT but activates when market price moves in the favorable direction.

      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.

      Available timeInForce options, setting how long the order should be active before expiration:

      TIF Description
      GTC Good 'til Canceled – the order will remain on the book until you cancel it, or the order is completely filled.
      IOC Immediate or Cancel – the order will be filled for as much as possible, the unfilled quantity immediately expires.
      FOK Fill or Kill – the order will expire unless it cannot be immediately filled for the entire quantity.

      Notes:

      newClientOrderId specifies clientOrderId value for the order.

      A new order with the same clientOrderId is accepted only when the previous one is filled or expired.

      Any LIMIT or LIMIT_MAKER order can be made into an iceberg order by specifying the icebergQty.

      An order with an icebergQty must have timeInForce set to GTC.

      Trigger order price rules for STOP_LOSS/TAKE_PROFIT orders:

      stopPrice must be above market price: STOP_LOSS BUY, TAKE_PROFIT SELL stopPrice must be below market price: STOP_LOSS SELL, TAKE_PROFIT BUY

      MARKET orders using quoteOrderQty follow LOT_SIZE filter rules.

      The order will execute a quantity that has notional value as close as possible to requested quoteOrderQty.

      Parameters

      Returns Promise<WebsocketApiResponse<OrderPlaceResponse>>

      TradeApi

      Binance API Documentation

    Settings

    Member Visibility

    On This Page

    Constructors
    Methods