Change Log

2026-05-19

Rest API changed.

Updated Endpoint — New Order (SIGNED)

POST /open/v1/orders

• Add selfTradePreventionMode (INT, optional) — 0 EXPIRE_MAKER, 1 EXPIRE_TAKER, 2 EXPIRE_BOTH, 3 NONE, 4 DECREMENT, 5 TRANSFER

Updated Endpoint — Get all Supported Trading Symbol

GET /open/v1/common/symbols

• Add defaultSelfTradePreventionMode to symbol response
• Add allowedSelfTradePreventionModes to symbol response

Updated Documentation — FAQs

• Add Self Trade Prevention (STP) FAQ section to FAQs.md

2026-04-13

Rest API changed.

New Endpoint — Query Execution Rules

GET /api/v3/executionRules

New Documentation — FAQs

• Add FAQs.md with Price Range Execution Rule documentation

2026-04-07

Rest API changed.

Updated Endpoint — Account Information (SIGNED)

GET /open/v1/account/spot

• Add fiatMakerCommission — Maker commission rate for TRY (fiat) pairs
• Add fiatTakerCommission — Taker commission rate for TRY (fiat) pairs

2026-03-26

• Add deprecation notice to POST /open/v1/user-data-stream, PUT /open/v1/user-data-stream, DELETE /open/v1/user-data-stream

  • Please switch to POST /open/v1/user-listen-token
  • These endpoints are scheduled to be decommissioned on April 30, 2026

• Add new endpoint POST /open/v1/user-listen-token

  • Create a listen token for WebSocket API user data stream subscription

• Add WebSocket API documentation for user data stream

  • Subscribe with listenToken
  • Unsubscribe
  • Event: Stream Terminated

2026-03-23

Rest API changed.

New Endpoint — Batch Cancel Orders (SIGNED)

POST /open/v1/orders/batch-cancel

Updated Endpoint — New Order (SIGNED)

POST /open/v1/orders

• Add timeInForce parameter

2025-09-23

Wallet Endpoints Changed

Add Withdraw History (SIGNED)

⁠GET /open/v1/fiat/deposits (Deposit History)

⁠GET /open/v1/fiat/withdraws (Withdraw History)

2025-06-23

Public API Definitions adds limit maker type

2025-03-18

Rest API changed.

Public API Definitions Add order types 3,4,5,6,7

Withdraw (SIGNED) Add new parameters

2023-09-06

User Data Streams changed.

Create a listenKey:

POST /open/v1/user-data-stream (when symbolType is 1, MBX symbol)

POST /open/v1/private-n/user-data-stream (when symbolType is 3, Nextme Symbol(New Symbol) )

Ping/Keep-alive a listenKey:

PUT /open/v1/user-data-stream (when symbolType is 1, MBX symbol)

PUT /open/v1/private-n/user-data-stream (when symbolType is 3, Nextme Symbol(New Symbol) )

Close a listenKey:

DELETE /open/v1/user-data-stream (when symbolType is 1, MBX symbol)

DELETE /open/v1/private-n/user-data-stream (when symbolType is 3, Nextme Symbol(New Symbol) )

2023-08-16

General WSS information changed.

Changes ws link:

• wss://www.binance.tr(when symbol type is 2)
• wss://stream-tr.2meta.app(when symbol type is 3)

API Document Description

General API Information

• Some endpoints will require an API Key.
• The base endpoint is: https://www.binance.tr
• Some specified APIs another base endpoint is: https://api.binance.me
• All endpoints return a JSON object.
• Data is returned in ascending order. Oldest first, newest last.
• All time and timestamp related fields are in milliseconds.

HTTP Return Codes

• HTTP 4XX return codes are used for malformed requests; the issue is on the sender's side.

• HTTP 403 return code is used when the WAF Limit (Web Application Firewall) has been violated.

• HTTP 429 return code is used when breaking a request rate limit.

• HTTP 418 return code is used when an IP has been auto-banned for continuing to send requests after receiving 429 codes.

• HTTP 5XX return codes are used for internal errors; the issue is on Server's side. It is important to NOT treat this as a failure operation; the execution status is UNKNOWN and could have been a success.

Response fields description

General Information on Endpoints

• For GET endpoints, parameters must be sent as a query string.
• For POST endpoints, the parameters may be sent as a query string or in the request body with content type application/x-www-form-urlencoded. You may mix parameters between both the query string and request body if you wish to do so.
• Parameters may be sent in any order.
• If a parameter sent in both the query string and request body, the body string parameter will be used.

LIMITS

General Info on Limits

• The following intervalLetter values for headers:

  • SECOND => S
  • MINUTE => M
  • HOUR => H
  • DAY => D
• intervalNum describes the amount of the interval. For example, intervalNum 5 with intervalLetter M means "Every 5 minutes".
• A 429 will be returned when either rate limit is violated.

IP Limits

• Every request will contain X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) in the response headers which has the current used weight for the IP for all request rate limiters defined.
• Each route has a weight which determines for the number of requests each endpoint counts for. Heavier endpoints and endpoints that do operations on multiple symbols will have a heavier weight.
• When a 429 is received, it's your obligation as an API to back off and not spam the API.
• Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban (HTTP status 418).
• IP bans are tracked and scale in duration for repeat offenders, from 2 minutes to 3 days.
• A Retry-After header is sent with a 418 or 429 responses and will give the number of seconds required to wait, in the case of a 418, to prevent a ban, or, in the case of a 429, until the ban is over.
• The limits on the API are based on the IPs, not the API keys.

 We recommend using the websocket for getting data as much as possible, as this will not count to the request rate limit.

Order Rate Limits

• Every successful order response will contain a X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter) header which has the current order count for the account for all order rate limiters defined.
• Rejected/unsuccessful orders are not guaranteed to have X-MBX-ORDER-COUNT-** headers in the response.
• The order rate limit is counted against each account.

Endpoint security type

• Each endpoint has a security type that determines the how you will interact with it. This is stated next to the NAME of the endpoint.

  • If no security type is stated, assume the security type is NONE.
• API-keys are passed into the Rest API via the X-MBX-APIKEY header.
• API-keys and secret-keys are case sensitive.
• API-keys can be configured to only access certain types of secure endpoints. For example, one API-key could be used for SIGNED only, while another API-key can access everything except for SIGNED routes.
• By default, API-keys can access all secure routes.

SIGNED Endpoint security

• SIGNED endpoints require an additional parameter, signature, to be sent in the query string or request body.

• Endpoints use HMAC SHA256 signatures. The HMAC SHA256 signature is a keyed HMAC SHA256 operation. Use your secretKey as the key and totalParams as the value for the HMAC operation.

• The signature is not case sensitive.

• totalParams is defined as the query string concatenated with the request body.

Timing security

• A SIGNED endpoint also requires a parameter, timestamp, to be sent which should be the millisecond timestamp of when the request was created and sent.

• An additional parameter, recvWindow, may be sent to specify the number of milliseconds after timestamp the request is valid for. If recvWindow is not sent, it defaults to 5000.

• The logic is as follows:

  if (timestamp < (serverTime + 1000) && (serverTime - timestamp) <= recvWindow)
   {
     // process request
   } 
   else 
   {
     // reject request
   }

  Serious trading is about timing. Networks can be unstable and unreliable, which can lead to requests taking varying amounts of time to reach the servers. With recvWindow, you can specify that the request must be processed within a certain number of milliseconds or be rejected by the server.

It is recommended to use a small recvWindow of 5000 or less! The max cannot go beyond 60,000!

SIGNED Endpoint Examples for POST /open/v1/orders

Here is a step-by-step example of how to send a vaild signed payload from the Linux command line using echo, openssl, and curl.

Example 1: As a request body

• requestBody: symbol=BTC_USDT&side=0&type=1&quantity=0.16&price=7500×tamp=1581720670624&recvWindow=5000

• HMAC SHA256 signature:

  [linux]$ echo -n "symbol=BTC_USDT&side=0&type=1&quantity=0.16&price=7500&timestamp=1581720670624&recvWindow=5000" | openssl dgst -sha256 -hmac "cfDC92B191b9B3Ca3D842Ae0e01108CBKI6BqEW6xr4NrPus3hoZ9Ze9YrmWwPFV"
  (stdin)= 33824b5160daefc34257ab9cd3c3db7a0158a446674f896c9fc3b122ae656bfa
  

• curl command:

  (HMAC SHA256)
  [linux]$  curl -H "X-MBX-APIKEY: cfDC92B191b9B3Ca3D842Ae0e01108CBKI6BqEW6xr4NrPus3hoZ9Ze9YrmWwPFV" -X POST 'https://www.binance.tr/open/v1/orders' -d 'symbol=BTC_USDT&side=0&type=1&quantity=0.16&price=7500&timestamp=1581720670624&recvWindow=5000&signature=33824b5160daefc34257ab9cd3c3db7a0158a446674f896c9fc3b122ae656bfa'
  

Example 2: As a query string

• queryString: symbol=BTC_USDT&side=0&type=1&quantity=0.16&price=7500×tamp=1581720670624&recvWindow=5000

• HMAC SHA256 signature:

  [linux]$ echo -n "symbol=BTC_USDT&side=0&type=1&quantity=0.16&price=7500&timestamp=1581720670624&recvWindow=5000" | openssl dgst -sha256 -hmac "cfDC92B191b9B3Ca3D842Ae0e01108CBKI6BqEW6xr4NrPus3hoZ9Ze9YrmWwPFV"
  (stdin)= 33824b5160daefc34257ab9cd3c3db7a0158a446674f896c9fc3b122ae656bfa
  

• curl command:

  (HMAC SHA256)
  [linux]$ curl -H "X-MBX-APIKEY: cfDC92B191b9B3Ca3D842Ae0e01108CBKI6BqEW6xr4NrPus3hoZ9Ze9YrmWwPFV" -X POST 'https://www.binance.tr/open/v1/orders?symbol=BTC_USDT&side=0&type=1&quantity=0.16&price=7500&timestamp=1581720670624&recvWindow=5000&signature=33824b5160daefc34257ab9cd3c3db7a0158a446674f896c9fc3b122ae656bfa'
  

Example 3: Mixed query string and request body

• queryString: symbol=BTC_USDT&side=0&type=1

• requestBody: quantity=1&price=0.1&recvWindow=5000×tamp=1499827319559

• requestBody: symbol=BTC_USDT&side=0&type=1quantity=0.16&price=7500×tamp=1581720670624&recvWindow=5000

• HMAC SHA256 signature:

  [linux]$ echo -n "symbol=BTC_USDT&side=0&type=1quantity=0.16&price=7500&timestamp=1581720670624&recvWindow=5000" | openssl dgst -sha256 -hmac "cfDC92B191b9B3Ca3D842Ae0e01108CBKI6BqEW6xr4NrPus3hoZ9Ze9YrmWwPFV"
  (stdin)= 27dbb813ab6ee7ef61902f88f1a0a6cd4daca0503a5195dbdd3174f49a61ad79
  

• curl command:

  (HMAC SHA256)
  [linux]$ curl -H "X-MBX-APIKEY: cfDC92B191b9B3Ca3D842Ae0e01108CBKI6BqEW6xr4NrPus3hoZ9Ze9YrmWwPFV" -X POST 'https://www.binance.tr/open/v1/orders?symbol=BTC_USDT&side=0&type=1' -d 'quantity=0.16&price=7500&timestamp=1581720670624&recvWindow=5000&signature=27dbb813ab6ee7ef61902f88f1a0a6cd4daca0503a5195dbdd3174f49a61ad79'
  

Note that the signature is different in example 3. There is no & between "1" and "quantity=1".

Public API Definitions

Terminology

• base asset refers to the asset that is the quantity of a symbol.
• quote asset refers to the asset that is the price of a symbol.

ENUM definitions

Symbol type:

• 1 MAIN
• 2 NEXT

Order status (status):

• -2 SYSTEM_PROCESSING
• 0 NEW
• 1 PARTIALLY_FILLED
• 2 FILLED
• 3 CANCELED
• 4 PENDING_CANCEL (currently unused)
• 5 REJECTED
• 6 EXPIRED

Order types (orderTypes, type):

• 1 LIMIT
• 2 MARKET
• 3 STOP_LOSS
• 4 STOP_LOSS_LIMIT
• 5 TAKE_PROFIT
• 6 TAKE_PROFIT_LIMIT
• 7 LIMIT_MAKER

Order side (side):

• 0 BUY
• 1 SELL

Kline/Candlestick chart intervals:

m -> minutes; h -> hours; d -> days; w -> weeks; M -> months

• 1m
• 3m
• 5m
• 15m
• 30m
• 1h
• 2h
• 4h
• 6h
• 8h
• 12h
• 1d
• 3d
• 1w
• 1M

Filters

Filters define trading rules on a symbol or an exchange. Filters come in two forms: symbol filters and exchange filters.

Symbol Filters

PRICE_FILTER

The PRICE_FILTER defines the price rules for a symbol. There are 3 parts:

• minPrice defines the minimum price/stopPrice allowed; disabled on minPrice == 0.
• maxPrice defines the maximum price/stopPrice allowed; disabled on maxPrice == 0.
• tickSize defines the intervals that a price/stopPrice can be increased/decreased by; disabled on tickSize == 0.

Any of the above variables can be set to 0, which disables that rule in the price filter. In order to pass the price filter, the following must be true for price/stopPrice of the enabled rules:

• price >= minPrice
• price <= maxPrice
• (price-minPrice) % tickSize == 0

/exchangeInfo format:

PERCENT_PRICE

The PERCENT_PRICE filter defines valid range for a price based on the average of the previous trades. avgPriceMins is the number of minutes the average price is calculated over. 0 means the last price is used.

In order to pass the percent price, the following must be true for price:

• price <= weightedAveragePrice * multiplierUp
• price >= weightedAveragePrice * multiplierDown

/exchangeInfo format:

LOT_SIZE

The LOT_SIZE filter defines the quantity (aka "lots" in auction terms) rules for a symbol. There are 3 parts:

• minQty defines the minimum quantity/icebergQty allowed.
• maxQty defines the maximum quantity/icebergQty allowed.
• stepSize defines the intervals that a quantity/icebergQty can be increased/decreased by.

In order to pass the lot size, the following must be true for quantity/icebergQty:

• quantity >= minQty
• quantity <= maxQty
• (quantity-minQty) % stepSize == 0

/exchangeInfo format:

NOTIONAL

The NOTIONAL filter defines the minimum notional value allowed for an order on a symbol. An order's notional value is the price * quantity. applyToMarket determines whether or not the NOTIONAL filter will also be applied to MARKET orders. Since MARKET orders have no price, the average price is used over the last avgPriceMins minutes. avgPriceMins is the number of minutes the average price is calculated over. 0 means the last price is used.

/exchangeInfo format:

ICEBERG_PARTS

The ICEBERG_PARTS filter defines the maximum parts an iceberg order can have. The number of ICEBERG_PARTS is defined as CEIL(qty / icebergQty).

/exchangeInfo format:

MARKET_LOT_SIZE

The MARKET_LOT_SIZE filter defines the quantity (aka "lots" in auction terms) rules for MARKET orders on a symbol. There are 3 parts:

• minQty defines the minimum quantity allowed.
• maxQty defines the maximum quantity allowed.
• stepSize defines the intervals that a quantity can be increased/decreased by.

In order to pass the market lot size, the following must be true for quantity:

• quantity >= minQty
• quantity <= maxQty
• (quantity-minQty) % stepSize == 0

/exchangeInfo format:

MAX_NUM_ORDERS

The MAX_NUM_ORDERS filter defines the maximum number of orders an account is allowed to have open on a symbol. Note that both "algo" orders and normal orders are counted for this filter.

/exchangeInfo format:

MAX_NUM_ALGO_ORDERS

The MAX_NUM_ALGO_ORDERS filter defines the maximum number of "algo" orders an account is allowed to have open on a symbol. "Algo" orders are STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, and TAKE_PROFIT_LIMIT orders.

/exchangeInfo format:

MAX_NUM_ICEBERG_ORDERS

The MAX_NUM_ICEBERG_ORDERS filter defines the maximum number of ICEBERG orders an account is allowed to have open on a symbol. An ICEBERG order is any order where the icebergQty is > 0.

/exchangeInfo format:

Exchange Filters

EXCHANGE_MAX_NUM_ORDERS

The MAX_NUM_ORDERS filter defines the maximum number of orders an account is allowed to have open on the exchange. Note that both "algo" orders and normal orders are counted for this filter.

/exchangeInfo format:

EXCHANGE_MAX_NUM_ALGO_ORDERS

The MAX_ALGO_ORDERS filter defines the maximum number of "algo" orders an account is allowed to have open on the exchange. "Algo" orders are STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, and TAKE_PROFIT_LIMIT orders.

/exchangeInfo format:

General endpoints

Check server time

GET /open/v1/common/time

Test connectivity to the Rest API and get the current server time.

Parameters: NONE

Response:

Get all Supported Trading Symbol

GET /open/v1/common/symbols

This endpoint returns all Exchange's supported trading symbol.

Parameters: NONE

Response:

Query Execution Rules

GET /api/v3/executionRules

Weight:

Parameters:

Notes:

• No combination of multiple parameters is allowed.

Data Source: Memory

Response:

Market Data endpoints

Order book

GET https://api.binance.me/api/v3/depth (when symbol type is 1)
GET https://cloudme-tr.2meta.app/api/v1/depth (when symbol type is 3)

Parameters:

Response:

Recent trades list

GET https://api.binance.me/api/v3/trades (when symbol type is 1)
GET /open/v1/market/trades (when symbol type is not 1)

Get recent trades (up to last 500).

Parameters:

Response:

Compressed/Aggregate trades list

GET https://api.binance.me/api/v3/aggTrades (when symbol type is 1)
GET https://cloudme-tr.2meta.app/api/v1/aggTrades (when symbol type is 3)

Get compressed, aggregate trades. Trades that fill at the time, from the same order, with the same price will have the quantity aggregated.

Parameters:

• If fromId, startTime, and endTime are not sent, the most recent aggregate trades will be returned.

Response:

Kline/Candlestick data

GET https://api.binance.me/api/v1/klines (when symbol type is 1)
GET https://cloudme-tr.2meta.app/api/v1/klines (when symbol type is 3)

Kline/candlestick bars for a symbol. Klines are uniquely identified by their open time.

Parameters:

• If startTime and endTime are not sent, the most recent klines are returned.

Response:

Account endpoints

New order (SIGNED)

POST /open/v1/orders  (HMAC SHA256)

Send in a new order.

Parameters:

Additional mandatory parameters based on type:

Other info:

• LIMIT_MAKER are LIMIT orders that will be rejected if they would immediately match and trade as a taker.
• STOP_LOSS and TAKE_PROFIT will execute a MARKET order when the stopPrice is reached.
• 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.
• MARKET orders using quantity specifies how much a user wants to buy or sell based on the market price.
• MARKET orders using quoteOrderQty specifies the amount the user wants to spend (when buying) of the quote asset; the correct quantity will be determined based on the market liquidity and quoteOrderQty.
• 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

Response:

Query order (SIGNED)

GET /open/v1/orders/detail (HMAC SHA256)

Check an order's status.

Parameters:

Response:

Cancel order (SIGNED)

POST /open/v1/orders/cancel  (HMAC SHA256)

Cancel an active order.

Parameters:

Response:

Batch cancel orders (SIGNED)

POST /open/v1/orders/batch-cancel  (HMAC SHA256)

Cancel multiple active orders. Either symbol or orderIds must be sent.

Parameters:

Notes:

• Either symbol or orderIds must be sent.

Response:

All orders (SIGNED)

GET /open/v1/orders (HMAC SHA256)

Get all account orders; active, canceled, or filled.

Parameters:

Notes:

• if field "fromId" is defined, this field "direct" becomes mandatory.

Response:

New OCO (SIGNED)

POST /open/v1/orders/oco (HMAC SHA256)

Send in a new OCO

Parameters:

Additional Info:

• Price Restrictions:

  • SELL: Limit Price > Last Price > Stop Price
  • BUY: Limit Price < Last Price < Stop Price

Response:

Account information (SIGNED)

GET /open/v1/account/spot (HMAC SHA256)

Get current account information.

Parameters:

Response:

Response fields:

Account Asset information (SIGNED)

GET /open/v1/account/spot/asset (HMAC SHA256)

Get current account information for a specific asset.

Parameters:

Response:

Account trade list (SIGNED)

GET /open/v1/orders/trades  (HMAC SHA256)

Get trades for a specific account and symbol.

Parameters:

Notes:

• if field "fromId" is defined, this field "direct" becomes mandatory.

Response:

Wallet Endpoints

Withdraw (SIGNED)

POST /open/v1/withdraws (HMAC SHA256)

Submit a withdraw request.

Parameters:

Response:

Withdraw History (SIGNED)

GET /open/v1/withdraws (HMAC SHA256)

Fetch withdraw history.

Parameters:

Response:

Fiat Withdraw History (SIGNED)

GET /open/v1/fiat/withdraws (HMAC SHA256)

Fetch fiat withdraw history.

Parameters:

Response:

Deposit History (SIGNED)

GET /open/v1/deposits (HMAC SHA256)

Fetch deposit history. Parameters: Name | Type | Mandatory | Description ------------ | ------------ | ------------ | ------------ asset | STRING | NO status | INT | NO | 0(0:pending, 1:success) fromId | LONG | NO | ID to fetch from. Default gets most recent records. startTime | LONG | NO endTime | LONG | NO recvWindow | LONG | NO timestamp | LONG | YES Response:

Fiat Deposit History (SIGNED)

GET /open/v1/fiat/deposits (HMAC SHA256)

Fetch fiat deposit history.

Parameters:

Response:

Deposit Address (SIGNED)

GET  /open/v1/deposits/address (HMAC SHA256)

Fetch deposit address.

Parameters:

Response:

General WSS information

• The base endpoint is:

1. wss://stream-cloud.binance.tr(when symbol type is 1, replace _ of symbol with null string and convert symbol to lowercase)
2. wss://stream-tr.2meta.app(when symbol type is 3)

• Streams can be accessed either in a single raw stream or in a combined stream
• Raw streams are accessed at /ws/\<streamName>
• Combined streams are accessed at /stream?streams=\<streamName1>/\<streamName2>/\<streamName3>
• Combined stream events are wrapped as follows: {"stream":"\<streamName>","data":\<rawPayload>}
• A single connection to stream-cloud.binance.tr www.binance.tr is only valid for 24 hours; expect to be disconnected at the 24 hour mark
• The websocket server will send a ping frame every 3 minutes. If the websocket server does not receive a pong frame back from the connection within a 10 minute period, the connection will be disconnected. Unsolicited pong frames are allowed.

Live Subscribing/Unsubscribing to streams

• The following data can be sent through the websocket instance in order to subscribe/unsubscribe from streams. Examples can be seen below.
• The id used in the JSON payloads is an unsigned INT used as an identifier to uniquely identify the messages going back and forth.
• In the response, if the result received is null this means the request sent was a success for non-query requests (e.g. Subscribing/Unsubscribing).

Subscribe to a stream

• Request

  {
    "method": "SUBSCRIBE",
    "params": [
      "btcusdt@aggTrade",
      "btcusdt@depth"
    ],
    "id": 1
  }

• Response

  {
    "result": null,
    "id": 1
  }

Unsubscribe to a stream

• Request

  {
    "method": "UNSUBSCRIBE",
    "params": [
      "btcusdt@depth"
    ],
    "id": 312
  }

• Response

  {
    "result": null,
    "id": 312
  }

Listing Subscriptions

• Request

  {
    "method": "LIST_SUBSCRIPTIONS",
    "id": 3
  }

• Response

  {
    "result": [
      "btcusdt@aggTrade"
    ],
    "id": 3
  }

Setting Properties

Currently, the only property can be set is to set whether combined stream payloads are enabled are not. The combined property is set to false when connecting using /ws/ ("raw streams") and true when connecting using /stream/.

• Request

  {
    "method": "SET_PROPERTY",
    "params": [
      "combined",
      true
    ],
    "id": 5
  }

• Response

  {
    "result": null,
    "id": 5
  }

Retrieving Properties

• Request

  {
    "method": "GET_PROPERTY",
    "params": [
      "combined"
    ],
    "id": 2
  }

• Response

  {
    "result": true, // Indicates that combined is set to true.
    "id": 2
  }

Error Messages

Detailed Stream information

Aggregate Trade Streams

The Aggregate Trade Streams push trade information that is aggregated for a single taker order.

Stream Name: \<symbol>@aggTrade

Update Speed: Real-time

Payload:

Trade Streams

The Trade Streams push raw trade information; each trade has a unique buyer and seller.

Stream Name: \<symbol>@trade

Update Speed: Real-time

Payload:

Kline/Candlestick Streams

The Kline/Candlestick Stream push updates to the current klines/candlestick every second.

Kline/Candlestick chart intervals:

m -> minutes; h -> hours; d -> days; w -> weeks; M -> months

• 1m
• 3m
• 5m
• 15m
• 30m
• 1h
• 2h
• 4h
• 6h
• 8h
• 12h
• 1d
• 3d
• 1w
• 1M

Stream Name: \<symbol>@kline_\<interval>

Update Speed: 2000ms

Payload:

Individual Symbol Mini Ticker Stream

24hr rolling window mini-ticker statistics. These are NOT the statistics of the UTC day, but a 24hr rolling window for the previous 24hrs.

Stream Name: \<symbol>@miniTicker

Update Speed: 1000ms

Payload:

All Market Mini Tickers Stream

24hr rolling window mini-ticker statistics for all symbols that changed in an array. These are NOT the statistics of the UTC day, but a 24hr rolling window for the previous 24hrs. Note that only tickers that have changed will be present in the array.

Stream Name: !miniTicker@arr

Update Speed: 1000ms

Payload:

Partial Book Depth Streams

Top \<levels> bids and asks, pushed every second. Valid \<levels> are 5, 10, or 20.

Stream Names: \<symbol>@depth\<levels> OR \<symbol>@depth\<levels>@100ms

Update Speed: 1000ms or 100ms

Payload:

Diff. Depth Stream

Order book price and quantity depth updates used to locally manage an order book.

Stream Name: \<symbol>@depth OR \<symbol>@depth@100ms

Update Speed: 1000ms or 100ms

Payload:

How to manage a local order book correctly

1. Open a stream to wss://stream-cloud.binance.tr/ws/bnbbtc@depth.
2. Buffer the events you receive from the stream.
3. Get a depth snapshot from https://api.binance.me/api/v3/depth?symbol=BNBBTC&limit=1000 .
4. Drop any event where u is <= lastUpdateId in the snapshot.
5. The first processed event should have U <= lastUpdateId+1 AND u >= lastUpdateId+1.
6. While listening to the stream, each new event's U should be equal to the previous event's u+1.
7. The data in each event is the absolute quantity for a price level.
8. If the quantity is 0, remove the price level.
9. Receiving an event that removes a price level that is not in your local order book can happen and is normal.

General WSS information

• The base API endpoint is: https://www.binance.tr
• A User Data Stream listenKey is valid for 60 minutes after creation.
• Doing a PUT on a listenKey will extend its validity for 60 minutes.
• Doing a DELETE on a listenKey will close the stream.
• The base websocket endpoint is: stream.binance.com stream-cloud.binanceru.net (when symbol type is 1)
• User Data Streams are accessed at /ws/\<listenKey>
• A single connection to stream.binance.com stream-cloud.binanceru.net is only valid for 24 hours; expect to be disconnected at the 24 hour mark
• User data stream payloads are not guaranteed to be in order during heavy periods; make sure to order your updates using E
• User Data Streams does not support symbols with symbol type 2 now

Create a listenKey

POST /open/v1/user-data-stream (when symbolType is 1, MBX symbol)

POST /open/v1/private-n/user-data-stream (when symbolType is 3, Nextme Symbol(New Symbol) )

Notice: For symbolType 1 (MBX symbol), this interface will be deprecated soon. Please switch to POST /open/v1/user-listen-token. For symbolType 3, no change is required.

Start a new user data stream. The stream will close after 60 minutes unless a keepalive is sent.

Weight: 1

Parameters: NONE

Response:

Ping/Keep-alive a listenKey

PUT /open/v1/user-data-stream (when symbolType is 1, MBX symbol)

PUT /open/v1/private-n/user-data-stream (when symbolType is 3, Nextme Symbol(New Symbol) )

Notice: For symbolType 1 (MBX symbol), this interface will be deprecated soon. Please switch to POST /open/v1/user-listen-token. For symbolType 3, no change is required.

Keepalive a user data stream to prevent a time out. User data streams will close after 60 minutes. It's recommended to send a ping about every 30 minutes.

Weight: 1

Parameters:

Response:

Close a listenKey

DELETE /open/v1/user-data-stream (when symbolType is 1, MBX symbol)

DELETE /open/v1/private-n/user-data-stream (when symbolType is 3, Nextme Symbol(New Symbol) )

Notice: For symbolType 1 (MBX symbol), this interface will be deprecated soon. Please switch to POST /open/v1/user-listen-token. For symbolType 3, no change is required.

Close out a user data stream.

Weight: 1

Parameters:

Response:

Create a listenToken (Signed)

POST /open/v1/user-listen-token

Create a new listen token for user data stream subscription via WebSocket API.

Weight: 1

Parameters:

Response:

Notes:

• The token validity is determined by the validity parameter; default is 24 hours, maximum 24 hours. expirationTime = current time + validity.
• The response returns the token and expirationTime.

WebSocket API

General Information

• The WebSocket API base endpoint is: wss://ws-api.binance.tr:443/ws-api/v3
• The endpoint can also be obtained from /v1/common/system-config (field: binanceWssApiBaseUrl or binanceWssApiBaseUrlList)
• Use the listenToken obtained from POST /open/v1/user-listen-token to subscribe to user data streams
• listenToken subscription does not require an authenticated session
• Tokens will NOT auto-renew; you must obtain a new token and re-subscribe before expiration
• Renewal flow: POST /open/v1/user-listen-token for new token → subscribe.listenToken with new token
• Maximum 1,000 active subscriptions per WebSocket session
• websocket-api only for symbolType is 1, MBX symbol

Subscribe with listenToken

Subscribe to user data stream using a listenToken.

Method: userDataStream.subscribe.listenToken

Weight: 2

Parameters:

Request:

Response:

Notes:

• Non-authenticated sessions are allowed to use this feature.
• The subscription is not automatically renewed by the WebSocket API.
• To extend the validity of your subscription, you must call POST /open/v1/user-listen-token before the expiration of your current subscription, obtain a new listenToken with an updated expirationTime, and call userDataStream.subscribe.listenToken again passing the new listenToken. This will seamlessly extend your subscription to the new expirationDate.
• If the subscription is not extended, it will expire and you will receive a eventStreamTerminated event (see example below).

Unsubscribe

Unsubscribe from user data stream.

Method: userDataStream.unsubscribe

Weight: 2

Parameters:

Request:

Response:

Event: Stream Terminated

When a subscription expires without renewal, the server will push an eventStreamTerminated event.

Payload:

Web Socket Payloads

Account Update

Account state is updated with the outboundAccountPosition event.

Payload:

Order Update

Orders are updated with the executionReport event. Check the API documentation and below for relevant enum definitions. Average price can be found by doing Z divided by z.

Payload:

Execution types:

• NEW
• CANCELED
• REPLACED (currently unused)
• REJECTED
• TRADE
• EXPIRED

Price Range Execution Rule

Disclaimer: The symbols and values used here are fictional and do not imply anything about the actual configuration of the live exchange.

What are execution rules?

Execution rules are trading rules enforced at order execution time. The only execution rule currently available is the Price Range rule.

What does the Price Range Execution Rule do?

This rule ensures trades may only execute at prices within and equal to a price range around a reference price.

How can I query the execution price range allowed for a symbol?

How can I query the reference price?

Note: The reference price is continually changing, so monitoring via WebSocket Streams is recommended.

How does the Price Range Execution Rule work?

Example execution rule for a hypothetical symbol:

Example reference price:

At time 1770736694138:

1. A BUY order may not execute at a price more than twice or less than half the reference price.
2. A SELL order may not execute at a price more than twice or less than half the reference price.

What happens if a symbol has no execution rule of type PRICE_RANGE and no reference price?

The Price Range Execution Rule is not enforced on the symbol.

What happens if a symbol has no execution rule of type PRICE_RANGE but does have a reference price?

The Price Range Execution Rule is not enforced on the symbol.

What happens if a symbol has an execution rule of type PRICE_RANGE but does not have a reference price?

The Price Range Execution Rule is not enforced on the symbol.

What happens if a symbol has an execution rule of type PRICE_RANGE that does not have all four multipliers?

When a multiplier is absent, the rule is not enforced for that order side and price direction. For example, if bidMultiplierDown were missing, a BUY order could execute at any price at or below twice the reference price.

What happens if the symbol's reference price is null?

The Price Range Execution Rule is not enforced on the symbol.

When are the execution price limits for an order set?

When an order enters its taker phase, the reference price is recalculated to set the execution price limits for the order's entire taker phase. A single taker order may match with many maker orders during this phase.

What happens if an order attempts to execute at a price outside of the allowed price range?

The taker order will be expired (status: EXPIRED) with expiry reason EXECUTION_RULE_PRICE_RANGE_EXCEEDED.

How is the reference price calculated?

• If calculated by the Matching Engine: "calculationType": "ARITHMETIC_MEAN"
• If calculated outside the matching engine: "calculationType": "EXTERNAL" (see below)

How does the Matching Engine calculate the reference price?

The matching engine computes a simple moving average of trade prices over a time window configured with bucketWidthMs (bucket width in milliseconds) and bucketCount. The product of these defines the window size.

When a trade occurs, the engine captures the price and adds it to the current bucket. Each bucket has:

• An open time aligned to engine time modulo the bucket width
• A trade count (fixed-point integer with four decimal places of precision)
• A sum of trade prices (fixed-point integer with four extra decimal places beyond quote asset precision)

The engine calculates a bucket's average by dividing sum by trade count. Buckets accumulate as trades occur; a bucket is dropped when its close time exits the window. Thus:

• The oldest bucket likely has an open time outside and a close time inside the window.
• The maximum number of buckets tracked by the engine is actually 1 more than the configured bucketCount.

The oldest time in the window is called the "cutoff time."

When the oldest bucket straddles the cutoff time, its contents are prorated:

• Expired fraction = (cutoff time − bucket's open time) / bucket width
• The bucket's trade count is reduced by the expired fraction
• The bucket's sum is reduced by the expired fraction
• The open time is set to the cutoff time

The reference price is the total of the sum in each bucket divided by the total of the trade count in each bucket. Division is truncating integer division.

How are reference prices calculated outside the matching engine?

If external, a query returns "externalCalculationId" followed by an integer. Each integer indicates a different calculation method.

External Reference Price Calculation Method 0

The reference price was set manually by a human operator. This calculation method will only be used in situations when algorithmic calculation of the reference price has been deemed unsuitable.

Self Trade Prevention (STP) FAQ

Disclaimer: The commissions and prices used here are fictional and do not imply anything about the actual setup on the live exchange.

What is Self Trade Prevention?

Self Trade Prevention (or STP) prevents orders of users to match against their own.

What defines a self-trade?

A self-trade can occur in either scenario:

• The order traded against the same account.

What happens when STP is triggered?

There are five possible modes for what the system does when an order would create a self-trade.

NONE - This mode exempts the order from self-trade prevention. Accounts or Trade group IDs will not be compared, no orders will be expired, and the trade will occur.

EXPIRE_TAKER - This mode prevents a trade by immediately expiring the taker order's remaining quantity.

EXPIRE_MAKER - This mode prevents a trade by immediately expiring the potential maker order's remaining quantity.

EXPIRE_BOTH - This mode prevents a trade by immediately expiring both the taker and the potential maker orders' remaining quantities.

DECREMENT - This mode increases the prevented quantity of both orders by the amount of the prevented match. The smaller of the two orders will expire, or both if they have the same quantity.

TRANSFER - If orders are from the same account, then the behavior is the same as DECREMENT. If orders are from different accounts with the same tradeGroupId, then in addition to the behavior of DECREMENT, the last prevented quantity and its notional are transferred between the two accounts.

STP behavior is typically determined by the STP mode of the taker order only. The exception is that for STP TRANSFER to occur, both the maker and taker orders must specify STP mode TRANSFER. If the taker order specifies STP mode TRANSFER, but the maker order specifies a different STP mode, then the STP behavior is DECREMENT.

In summary: