Class WebsocketAPIConnection

Get current account commission rates. Weight: 20

Query your current unfilled order count for all intervals. Weight: 40

Query information about your account. Weight: 20

Query information about all your order lists, filtered by time range. Weight: 20

Query information about all your orders – active, canceled, filled – filtered by time range. Weight: 20

Get current average price for a symbol. Weight: 2

Get current order book.

Note that this request returns limited market depth.

If you need to continuously monitor order book updates, please consider using WebSocket Streams:

<symbol>@depth<levels> <symbol>@depth

You can use depth request together with <symbol>@depth streams to maintain a local order book. Weight: Adjusted based on the limit:

Disconnects from the WebSocket server. If there is no active connection, a warning is logged. Otherwise, all connections in the connection pool are closed gracefully, and a message is logged indicating that the connection has been disconnected.

Query current exchange trading rules, rate limits, and symbol information. Weight: 20

Checks if the WebSocket connection is currently open.

Get klines (candlestick bars).

Klines are uniquely identified by their open & close time.

If you need access to real-time kline updates, please consider using WebSocket Streams:

<symbol>@kline_<interval>

If you need historical kline data, please consider using data.binance.vision. Weight: 2

Retrieves allocations resulting from SOR order placement. Weight: 20

Displays the list of orders that were expired due to STP.

These are the combinations supported:

symbol + preventedMatchId symbol + orderId symbol + orderId + fromPreventedMatchId (limit will default to 500) symbol + orderId + fromPreventedMatchId + limit

Query information about all your trades, filtered by time range.

Query execution status of all open order lists.

If you need to continuously monitor order status updates, please consider using WebSocket Streams:

userDataStream.start request executionReport user data stream event Weight: 6

Cancel all open orders on a symbol. This includes orders that are part of an order list. Weight: 1

Query execution status of all open orders.

If you need to continuously monitor order status updates, please consider using WebSocket Streams:

userDataStream.start request executionReport user data stream event Weight: Adjusted based on the number of requested symbols:

Reduce the quantity of an existing open order.

This adds 0 orders to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.

Read Order Amend Keep Priority FAQ to learn more. Weight: 4

Queries all amendments of a single order. Weight: 4

Cancel an active order. Weight: 1

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. Weight: 1

Cancel an active order list. Weight: 1

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: 1

Unfilled Order Count: 1

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: 1

Unfilled Order Count: 2

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: 1

Unfilled Order Count: 2

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: 1

Unfilled Order Count: 3

Check execution status of an Order list.

For execution status of individual orders, use order.status. Weight: 4

Send in a new order.

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

Check execution status of an order. Weight: 4

Test order placement.

Validates new order parameters and verifies your signature but does not send the order into the matching engine. Weight: |Condition| Request Weight| |------------ | ------------ | |Without computeCommissionRates| 1| |With computeCommissionRates|20|

Test connectivity to the WebSocket API. Weight: 1

Sends a ping message to all connected Websocket servers in the pool. If no connections are ready, a warning is logged. For each active connection, the ping message is sent, and debug logs provide details.

Sends an unsigned message to the WebSocket server

Sends a signed message to the WebSocket server with authentication

Authenticate WebSocket connection using the provided API key.

After calling session.logon, you can omit apiKey and signature parameters for future requests that require them.

Note that only one API key can be authenticated. Calling session.logon multiple times changes the current authenticated API key. Weight: 2

Forget the API key previously authenticated. If the connection is not authenticated, this request does nothing.

Note that the WebSocket connection stays open after session.logout request. You can continue using the connection, but now you will have to explicitly provide the apiKey and signature parameters where needed. Weight: 2

Query the status of the WebSocket connection, inspecting which API key (if any) is used to authorize requests. Weight: 2

Places an order using smart order routing (SOR).

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

Read SOR FAQ to learn more. Weight: 1

Unfilled Order Count: 1

Test new order creation and signature/recvWindow using smart order routing (SOR). Creates and validates a new order but does not send it into the matching engine. Weight: |Condition | Request Weight| |------------ | ------------ | |Without computeCommissionRates| 1 | |With computeCommissionRates |20 |

Get rolling window price change statistics with a custom window.

This request is similar to ticker.24hr, but statistics are computed on demand using the arbitrary window you specify. Weight: Adjusted based on the number of requested symbols:

Get 24-hour rolling window price change statistics.

If you need to continuously monitor trading statistics, please consider using WebSocket Streams:

<symbol>@ticker or !ticker@arr <symbol>@miniTicker or !miniTicker@arr

If you need different window sizes, use the ticker request. Weight: Adjusted based on the number of requested symbols:

Get the current best price and quantity on the order book.

If you need access to real-time order book ticker updates, please consider using WebSocket Streams:

<symbol>@bookTicker Weight: Adjusted based on the number of requested symbols:

Get the latest market price for a symbol.

If you need access to real-time price updates, please consider using WebSocket Streams:

<symbol>@aggTrade <symbol>@trade Weight: Adjusted based on the number of requested symbols:

Price change statistics for a trading day. Weight: 4 for each requested symbol.

The weight for this request will cap at 200 once the number of symbols in the request is more than 50.

Test connectivity to the WebSocket API and get the current server time. Weight: 1

Get aggregate trades.

An aggregate trade (aggtrade) represents one or more individual trades. Trades that fill at the same time, from the same taker order, with the same price – those trades are collected into an aggregate trade with total quantity of the individual trades.

If you need access to real-time trading activity, please consider using WebSocket Streams:

<symbol>@aggTrade

If you need historical aggregate trade data, please consider using data.binance.vision. Weight: 4

Get historical trades. Weight: 25

Get recent trades.

If you need access to real-time trading activity, please consider using WebSocket Streams:

<symbol>@trade Weight: 25

Get klines (candlestick bars) optimized for presentation.

This request is similar to klines, having the same parameters and response. uiKlines return modified kline data, optimized for presentation of candlestick charts. Weight: 2

Ping a user data stream to keep it alive.

User data streams close automatically after 60 minutes, even if you're listening to them on WebSocket Streams. In order to keep the stream open, you have to regularly send pings using the userDataStream.ping request.

It is recommended to send a ping once every 30 minutes. Weight: 2

Start a new user data stream. Weight: 2

Explicitly stop and close the user data stream. Weight: 2

Subscribe to the User Data Stream in the current WebSocket connection. Weight: 2