This will take effect on March 5, 2024.
Simple Binary Encoding (SBE) will be added to the live exchange, both for the Rest API and WebSocket API.
For more information on SBE, please refer to the FAQ
The SPOT WebSocket API can now support SBE on SPOT Testnet.
The SBE schema has been updated with WebSocket API metadata without incrementing either schemaId or version.
Users using SBE only on the REST API may continue to use the SBE schema with git commit hash 128b94b2591944a536ae427626b795000100cf1d or update to the newly-published SBE schema.
Users who want to use SBE on the WebSocket API must use the newly-published SBE schema.
The FAQ for SBE has been updated.
Simple Binary Encoding (SBE) has been added to SPOT Testnet.
This will be added to the live exchange at a later date.
For more information on what SBE is, please refer to the FAQ
Notice: The changes below are being rolled out gradually, and will take approximately a week to complete.
General Changes:
- Error message
Precision is over the maximum defined for this asset.has been changed toParameter '%s' has too much precision.- This error message is returned when a parameter has more precision than allowed:
e.g. if
base assetprecision is 6 andquantity=0.1234567then this error message will appear. - This affects all requests with the following parameters:
quantityquoteOrderQtyicebergQtylimitIcebergQtystopIcebergQtypricestopPricestopLimitPrice
- This error message is returned when a parameter has more precision than allowed:
e.g. if
- Requests for open OCO now correctly return results in ascending order. This affects the following requests:
- REST API:
GET /api/v3/openOrderList - WebSocket API:
openOrderList.status
- REST API:
- Requests for all OCO now correctly return results in ascending order when
startTimeorfromIdare specified. This affects the following requests:- REST API:
GET /api/v3/allOrderList - WebSocket API:
allOrderLists
- REST API:
- Fixed a bug where order query requests would incorrectly return
-2026 ORDER_ARCHIVEDerror for newly placed orders.- REST API:
GET /api/v3/order - WebSocket API:
order.status
- REST API:
REST API
- New endpoint
GET /api/v3/account/commission - New endpoint
GET /api/v3/ticker/tradingDay GET /api/v3/avgPriceresponse has a new fieldcloseTime, indicating the last trade time.GET /api/v3/klinesand/api/v3/uiKlineshave a new optional parametertimeZone.POST /api/v3/order/testandPOST /api/v3/sor/order/testhave a new optional parametercomputeCommissionRates.- Changes regarding invalid endpoints being sent:
- Previously, if you query an non-existing endpoint (e.g.
curl -X GET "https://api.binance.com/api/v3/exchangie) you would get a HTTP 404 code with the response<html><body><h2>404 Not found</h2></body></html> - From now on the HTML response will only appear if the Accept request header has
text/htmlfor this situation. The HTTP code will remain the same.
- Previously, if you query an non-existing endpoint (e.g.
WebSocket API
- New request
account.commission - New requests to allow session authentication: (Note that these requests can only be used with Ed25519 keys.)
session.logonsession.logoutsession.status
- New request
ticker.tradingDay avgPriceresponse has a new fieldcloseTime, indicating the last trade time.klinesanduiKlineshave a new optional parametertimeZone.order.testandsor.order.testhave a new optional parametercomputeCommissionRates.- Fixed a bug where unsolicited pongs sent before the ping would cause disconnection.
WebSocket Streams
- New stream
<symbol>@avgPrice idnow supports the same values as used foridin the WebSocket API:- 64-bit signed integers (previously this was unsigned)
- Alphanumeric strings, max of 36 in length
null
- Fixed a bug where unsolicited pongs sent before the ping would cause disconnection.
User Data Streams
- When an event of type
executionReporthas an execution type (x) ofTRADE_PREVENTION, fieldsl,LandYwill now always be 0. New fieldspl,pLandpYwill describe the prevented execution quantity, prevented execution price, and prevented execution notional instead. These new fields show the values of what wouldl,LandYhave been if the taker order didn't have self-trade prevention enabled.
The following will take effect approximately a week after the release date:
- Symbol Permissions will only affect order placement, not cancellation.
permissionsstill apply to Cancel-Replace orders (i.e. The cancellation won't be allowed if your account does have the permission to place an order using this request.)
Effective on 2023-10-19 00:00 UTC
- The request weights of the following requests have been increased:
| REST API | WebSocket API | Condition | Previous Request Weight | New Request Weight |
|---|---|---|---|---|
GET /api/v3/trades |
trades.recent |
N/A | 2 | 10 |
GET /api/v3/depth |
depth |
Limit 1-100 | 2 | 5 |
| Limit 101-500 | 10 | 25 | ||
| Limit 501-1000 | 20 | 50 | ||
| Limit 1001-5000 | 100 | 250 |
- Order decrement feature went live at 06:15 UTC.
- For more information on this feature, please refer to our FAQ
- For WebSocket API, removed
RAW REQUESTSrate limit inexchangeInfo, replaced it withCONNECTIONSrate limit, which is the limit for new Websocket connections.
The following changes will be effective from 2023-08-25 at UTC 00:00.
- The
CONNECTIONSrate limit for WebSocket API has been adjusted to 300 every 5 minutes. - The
REQUEST_WEIGHTrate limit for both REST and WebSocket API has been adjusted to 6,000 every minute. - The
RAW_REQUESTSrate limit for REST API has been adjusted to 61,000 every 5 minutes. - Previously, connecting to WebSocket API used to cost 1 weight. The cost is now 2.
- The weights to the following requests for both REST API and WebSocket API have been adjusted.
Please refer to the table for more details:
| Request | Previous Request Weight | New Request Weight |
|---|---|---|
GET /api/v3/order order.status |
2 | 4 |
GET /api/v3/orderList orderList.status |
2 | 4 |
GET /api/v3/openOrders openOrders.status - With symbol |
3 | 6 |
GET /api/v3/openOrders openOrders.status - Without symbol |
40 | 80 |
GET /api/v3/openOrderList openOrderLists.status |
3 | 6 |
GET /api/v3/allOrders allOrders |
10 | 20 |
GET /api/v3/allOrderList allOrderLists |
10 | 20 |
GET /api/v3/myTrades myTrades |
10 | 20 |
GET /api/v3/myAllocations myAllocations |
10 | 20 |
GET /api/v3/myPreventedMatches myPreventedMatches - Using preventedMatchId |
1 | 2 |
GET /api/v3/myPreventedMatches myPreventedMatches - Using orderId |
10 | 20 |
GET /api/v3/account account.status |
10 | 20 |
GET /api/v3/rateLimit/order account.rateLimits.orders |
20 | 40 |
GET /api/v3/exchangeInfo exchangeInfo |
10 | 20 |
GET /api/v3/depthdepth - Limit 1-100 |
1 | 2 |
GET /api/v3/depth depth - Limit 101-500 |
5 | 10 |
GET /api/v3/depth depth - Limit 501-1000 |
10 | 20 |
GET /api/v3/depth depth - Limit 1001-5000 |
50 | 100 |
GET /api/v3/aggTrades trades.aggregate |
1 | 2 |
GET /api/v3/trades trades.recent |
1 | 2 |
GET /api/v3/historicalTrades trades.historical |
5 | 10 |
GET /api/v3/klines klines |
1 | 2 |
GET /api/v3/uiKlines uiKlines |
1 | 2 |
GET /api/v3/ticker/bookTicker ticker.book - With symbol |
1 | 2 |
GET /api/v3/ticker/bookTicker ticker.book - Without symbol or With symbols |
2 | 4 |
GET /api/v3/ticker/priceticker.price - With symbol |
1 | 2 |
GET /api/v3/ticker/priceticker.price - Without symbol or With symbols |
2 | 4 |
GET /api/v3/ticker/24hr ticker.24hr - With symbol or With symbols using 1-20 symbols |
1 | 2 |
GET /api/v3/ticker/24hr ticker.24hr - With symbols using 21-100 symbols |
20 | 40 |
GET /api/v3/ticker/24hr ticker.24hr - Without symbol or symbols using 101 or more symbols |
40 | 80 |
GET /api/v3/avgPrice avgPrice |
1 | 2 |
GET /api/v3/ticker ticker |
2 | 4 |
GET /api/v3/ticker ticker - Maximum weight for this request |
100 | 200 |
POST /api/v3/userDataStream userDataStream.start |
1 | 2 |
PUT /api/v3/userDataStream userDataStream.ping |
1 | 2 |
DELETE /api/v3/userDataStreamuserDataStream.stop |
1 | 2 |
Smart Order Routing (SOR) has been added to the APIs. For more information please refer to our FAQ. Please wait for future announcements on when the feature will be enabled.
REST API
- Changes to
GET /api/v3/exchangeInfo:- New field in response:
sors, describing SORs enabled on the exchange.
- New field in response:
- Changes to
GET /api/v3/myPreventedMatches- New field
makerSymbolwill appear in the response for all prevented matches.
- New field
- New endpoints for order placement using SOR:
POST /api/v3/sor/orderPOST /api/v3/sor/order/test
- New endpoint
GET /api/v3/myAllocations
WEBSOCKET API
- Changes to
exchangeInfo:- New field in response:
sors, describing SORs enabled on the exchange.
- New field in response:
- Changes to
myPreventedMatches:- New field
makerSymbolwill appear in the response for all prevented matches.
- New field
- New requests for order placement using SOR:
sor.order.placesor.order.test
- New request
myAllocations
USER DATA STREAM
- Changes to
executionReport:- These fields are only relevant for orders placed using SOR:
- New field
bformatchType - New field
aforallocId - New field
kforworkingFloor
- New field
- This field is only relevant for orders expiring due to STP:
- New field
CsforcounterSymbol
- New field
- These fields are only relevant for orders placed using SOR:
- New API key type – Ed25519 – is now supported. (UI support will be released this week.)
- Ed25519 API keys are an alternative to RSA API keys, using asymmetric cryptography to authenticate your requests on the API.
- We recommend switching to Ed25519 for improved performance and security.
For more information, please refer to the API Key Types.
- Documentation has been updated with how to sign a payload with Ed25519 keys.
Notice: The change below are being rolled out, and will take approximately a week to complete.
General Changes:
- Changes to error messages:
- Previously, when duplicate symbols were passed to requests that do not allow it, the error would be "Mandatory parameter symbols was not sent, was empty/null, or malformed."
- Now, the error message is "Symbol is present multiple times in the list", with a new error code
-1151 - This affects the following requests:
GET /api/v3/exchangeInfoGET /api/v3/ticker/24hrGET /api/v3/ticker/priceGET/api/v3/ticker/bookTickerexchangeInfoticker.24hrticker.priceticker.book
- Fixed a bug where some non-archived orders being queried would receive the error code that their order was archived.
Rest API
- Changes to
GET /api/v3/account:- New field
preventSorwill appear in the response. - New field
uidthat shows the User Id/Account will appear in the response.
- New field
- Changes to
GET /api/v3/historicalTrades:- Changed security type from
MARKET_DATAtoNONE. - This means that the
X-MBX-APIKEYheader is no longer necessary and is now ignored.
- Changed security type from
Websocket API
- Changes to
account.status:- New field
preventSorwill appear in the response. - New field
uidthat shows the User Id/Account will appear in the response.
- New field
- Changes to
trades.historical:- Changed security type from
MARKET_DATAtoNONE. - This means that the
apiKeyparameter is no longer necessary and is now ignored.
- Changed security type from
The following changes will take effect approximately a week from the release date::
- Fixed multiple bugs with orders that use
type=MARKETandquoteOrderQty, also known as “reverse market orders”:- Reverse market orders are no longer partially filled, or filled for zero or negative quantity under extreme market conditions.
MARKET_LOT_SIZEfilter now correctly rejects reverse market orders that go over the symbol'smaxQty.
- Fixed a bug where OCO orders using
trailingDeltacould have an incorrecttrailingTimevalue after either leg of the OCO is touched. - New field
transactTimewill appear in order cancellation responses. This affects the following requests:DELETE /api/v3/orderPOST /api/v3/order/cancelReplaceDELETE /api/v3/openOrdersDELETE /api/v3/orderListorder.cancelorder.cancelReplaceopenOrders.cancelAllorderList.cancel
- A new endpoint is now available for redundancy: https://api-gcp.binance.com/
- This is using the GCP (Google Cloud Platform) CDN and may have slower performance compared to
api1-api4endpoints.
- This is using the GCP (Google Cloud Platform) CDN and may have slower performance compared to
Notice: The change below are being rolled out, and will take approximately a week to complete.
- The following base endpoints may give better performance but have less stability than https://api.binance.com:
- The previous market data URLs have been deprecated. Please update your code immediately to prevent interruption of our services.
- API Market data from
data.binance.comcan now be accessed fromdata-api.binance.vision. - Websocket Market Data from
data-stream.binance.comcan now be accessed fromdata-stream.binance.vision.
- API Market data from
Notice: All changes are being rolled out gradually to all our servers, and may take a week to complete.
GENERAL CHANGES
- The error messages for certain issues have been improved for easier troubleshooting.
| Situation | Old Error Message | New Error Message |
|---|---|---|
| An account cannot place or cancel an order, due to trading ability disabled. | This action is disabled on this account. | This account may not place or cancel orders. |
| When the permissions configured on the symbol do not match the permissions on the account. | This symbol is not permitted for this account. | |
| When the account tries to place an order on a symbol it has no permissions for. | This symbol is restricted for this account. | |
| Placing an order when symbol is not TRADING. | Unsupported order combination. | This order type is not possible in this trading phase. |
| Placing an order with timeinForce=IOC or FOK on a trading phase that does not support it. | Limit orders require GTC for this phase. |
- Fixed error message for querying archived orders:
- Previously, if an archived order (i.e. order with status
CANCELEDorEXPIREDwhereexecutedQty== 0 that occurred more than 90 days in the past.) is queried, the error message would be:
{ "code": -2013, "msg": "Order does not exist." }- Now, the error message is:
{ "code": -2026, "msg": "Order was canceled or expired with no executed qty over 90 days ago and has been archived." } - Previously, if an archived order (i.e. order with status
- Behavior for API requests with
startTimeandendTime:- Previously some requests failed if the
startTime==endTime. - Now, all API requests that accept
startTimeandendTimeallow the parameters to be equal. This applies to the following requests:- Rest API
GET /api/v3/aggTradesGET /api/v3/klinesGET /api/v3/allOrderListGET /api/v3/allOrdersGET /api/v3/myTrades
- Websocket API
trades.aggregateklinesallOrderListallOrdersmyTrades
- Rest API
- Previously some requests failed if the
- Users connected to the websocket API will now be disconnected if their IP is banned due to violation of the IP rate limits (status
418).
The following changes will take effect approximately a week from the release date, but the rest of the documentation has been updated to reflect the future changes:
- Changes to Filter Evaluation:
- Previous behavior:
LOT_SIZEandMARKET_LOT_SIZErequired that (quantity-minQty) %stepSize== 0. - New behavior: This has now been changed to (
quantity%stepSize) == 0.
- Previous behavior:
- Bug fix with reverse
MARKETorders (i.e.,MARKETusingquoteOrderQty):- Previous behavior: Reverse market orders would always have the status
FILLEDeven if the order did not fully fill due to low liquidity. - New behavior: If the reverse market order did not fully fill due to low liquidity the order status will be
EXPIRED, andFILLEDonly if the order was completely filled.
- Previous behavior: Reverse market orders would always have the status
REST API
- Changes to
DELETE /api/v3/orderandPOST /api/v3/order/cancelReplace:- A new optional parameter
cancelRestrictionsthat determines whether the cancel will succeed if the order status isNEWorPARTIALLY_FILLED. - If the order cancellation fails due to
cancelRestrictions, the error will be:
{ "code": -2011, "msg": "Order was not canceled due to cancel restrictions." } - A new optional parameter
WEBSOCKET API
- Changes to
order.cancelandorder.cancelReplace:- A new optional parameter
cancelRestrictionsthat determines whether the cancel will succeed if the order status isNEWorPARTIALLY_FILLED. - If the order cancellation fails due to
cancelRestrictions, the error will be:
{ "code": -2011, "msg": "Order was not canceled due to cancel restrictions." } - A new optional parameter
Changes to Websocket Limits
The WS-API and Websocket Stream now only allows 300 connections requests every 5 minutes.
This limit is per IP address.
Please be careful when trying to open multiple connections or reconnecting to the Websocket API.
As per the announcement, Self Trade Prevention will be enabled at 2023-01-26 08:00 UTC.
Please refer to GET /api/v3/exchangeInfo from the Rest API or exchangeInfo from the Websocket API on the default and allowed modes.
New API cluster has been added. Note that all endpoints are functionally equal, but may vary in performance.
New Feature: Self-Trade Prevention (aka STP) will be added to the system at a later date. This will prevent orders from matching with orders from the same account, or accounts under the same tradeGroupId.
Please refer to GET /api/v3/exchangeInfo from the Rest API or exchangeInfo from the Websocket API on the status.
"defaultSelfTradePreventionMode": "NONE", //If selfTradePreventionMode not provided, this will be the value passed to the engine
"allowedSelfTradePreventionModes": [ //What the allowed modes of selfTradePrevention are
"NONE",
"EXPIRE_TAKER",
"EXPIRE_BOTH",
"EXPIRE_MAKER"
]Additional details on the functionality of STP is explained in the STP FAQ document.
REST API
- New order status:
EXPIRED_IN_MATCH- This means that the order expired due to STP being triggered. - New endpoint:
GET /api/v3/myPreventedMatches- This queries the orders that expired due to STP being triggered.
- New optional parameter
selfTradePreventionModehas been added to the following endpoints:POST /api/v3/orderPOST /api/v3/order/ocoPOST /api/v3/cancelReplace
- New responses that will appear for all order placement endpoints if there was a prevented match (i.e. if an order could have matched with an order of the same account, or the accounts are in the same
tradeGroupId):tradeGroupId- This will only appear if account is configured to atradeGroupIdand if there was a prevented match.preventedQuantity- Only appears if there was a prevented match.- An array
preventedMatcheswith the following fields:preventedMatchIdmakerOrderIdpricetakerPreventedQuantity- This will only appear ifselfTradePreventionModeset isEXPIRE_TAKERorEXPIRE_BOTH.makerPreventedQuantity- This will only appear ifselfTradePreventionModeset isEXPIRE_MAKERorEXPIRE_BOTH.
- New fields
preventedMatchIdandpreventedQuantitythat can appear in the order query endpoints if the order had expired due to an STP trigger:GET /api/v3/orderGET /api/v3/openOrdersGET /api/v3/allOrders
WEBSOCKET API
- New order status:
EXPIRED_IN_MATCH- This means that the order expired due to STP being triggered. - New optional parameter
selfTradePreventionModehas been added to the following requests:order.placeorderList.placeorder.cancelReplace
- New request:
myPreventedMatches- This queries the orders that expired due to STP being triggered. - New responses that will appear for all order placement endpoints if there was a prevented match (i.e. if an order could have matched with an order of the same account, or the accounts are in the same
tradeGroupId):tradeGroupId- This will only appear if account is configured to atradeGroupIdand if there was a prevented match.preventedQuantity- Only appears if there was a prevented match.- An array
preventedMatcheswith the following fields:preventedMatchIdmakerOrderIdpricetakerPreventedQuantity- This will only appear ifselfTradePreventionModeset isEXPIRE_TAKERorEXPIRE_BOTH.makerPreventedQuantity- This will only appear ifselfTradePreventionModeset isEXPIRE_MAKERorEXPIRE_BOTH.
- New fields
preventedMatchIdandpreventedQuantitythat can appear in the order query requests if the order had expired due to STP trigger:order.statusopenOrders.statusallOrders
USER DATA STREAM
- New execution Type:
TRADE_PREVENTION - New fields for
executionReport(These fields will only appear if the order has expired due to STP trigger)u-tradeGroupIdv-preventedMatchIdU-counterOrderIdA-preventedQuantityB-lastPreventedQuantity
- SPOT WebSocket API documentation has been updated to show how to sign a request using an RSA key.
- Spot WebSocket API is now available on the live exchange.
- Spot Websocket API can be accessed through this URL:
wss://ws-api.binance.com/ws-api/v3
- New RSA signature
- Documentation has been updated to show how to create RSA keys.
- For security reasons, we recommend to use RSA keys instead of HMAC keys when generating an API key.
- We accept
PKCS#8(BEGIN PUBLIC KEY). - More details on how to upload your RSA public key will be added at a later date.
- SPOT WebSocket API is now available on SPOT Testnet.
- WebSocket API allows placing orders, canceling orders, etc. through a WebSocket connection.
- WebSocket API is a separate service from WebSocket Market Data streams. I.e., placing orders and listening to market data requires two separate WebSocket connections.
- WebSocket API is subject to the same Filter and Rate Limit rules as REST API.
- WebSocket API and REST API are functionally equivalent: they provide the same features, accept the same parameters, return the same status and error codes.
WEBSOCKET API WILL BE AVAILABLE ON THE LIVE EXCHANGE AT A LATER DATE.
REST API
Some error messages on error code -1003 have changed.
- Previous error message:
Too much request weight used; current limit is %s request weight per %s %s. Please use the websocket for live updates to avoid polling the API.has been updated to:
Too much request weight used; current limit is %s request weight per %s. Please use WebSocket Streams for live updates to avoid polling the API.
- Previous error message
Way too much request weight used; IP banned until %s. Please use the websocket for live updates to avoid bans.has been updated to:
Way too much request weight used; IP banned until %s. Please use WebSocket Streams for live updates to avoid bans.
Notice: These changes are being rolled out gradually to all our servers, and will take approximately a week to complete.
WEBSOCKET
!bookTickerwill be removed by December 7, 2022. Please use the Individual Book Ticker Streams instead (<symbol>@bookTicker).- Multiple
<symbol>@bookTickerstreams can be subscribed to over one connection. (E.g.wss://stream.binance.com:9443/stream?streams=btcusdt@bookTicker/bnbbtc@bookTicker)
- Multiple
REST API
- New error code
-1135- This error code will occur if a parameter requiring a JSON object is invalid.
- New error code
-1108- This error will occur if a value to a parameter being sent was too large, potentially causing overflow.
- This error code can occur in the following endpoints:
POST /api/v3/orderPOST /api/v3/order/cancelReplacePOST /api/v3/order/oco
- Changes to
GET /api/v3/aggTrades- Previous behavior:
startTimeandendTimehad to be used in combination and could only be an hour apart. - New behavior:
startTimeandendTimecan be used individually and the 1 hour limit has been removed.- When using
startTimeonly, this will return trades from that time, up to thelimitprovided. - When using
endTimeonly, this will return trades before that time, up to thelimitprovided. - If
limitnot provided, regardless of used in combination or sent individually, the endpoint will use the default limit.
- When using
- Previous behavior:
- Changes to
GET /api/v3/myTrades-
Fixed a bug where
symbol+orderIdcombination would return all trades even if the number of trades went beyond the500default limit. -
Previous behavior: The API would send specific error messages depending on the combination of parameters sent. E.g:
{ "code": -1106, "msg": "Parameter X was sent when not required." } -
New behavior: If the combinations of optional parameters to the endpoint were not supported, then the endpoint will respond with the generic error:
{ "code": -1128, "msg": "Combination of optional parameters invalid." } -
Added a new combination of supported parameters:
symbol+orderId+fromId. -
The following combinations of parameters were previously supported but no longer accepted, as these combinations were only taking
fromIdinto consideration, ignoringstartTimeandendTime:symbol+fromId+startTimesymbol+fromId+endTimesymbol+fromId+startTime+endTime
-
Thus, these are the supported combinations of parameters:
symbolsymbol+orderIdsymbol+startTimesymbol+endTimesymbol+fromIdsymbol+startTime+endTimesymbol+orderId+fromId
-
Note: These new fields will appear approximately a week from the release date.
- Changes to
GET /api/v3/exchangeInfo- New fields
defaultSelfTradePreventionModeandallowedSelfTradePreventionModes
- New fields
- Changes to the Order Placement Endpoints/Order Query/Order Cancellation Endpoints:
- New field
selfTradePreventionModewill appear in the response. - Affects the following endpoints:
POST /api/v3/orderPOST /api/v3/order/ocoPOST /api/v3/order/cancelReplaceGET /api/v3/orderDELETE /api/v3/orderDELETE /api/v3/orderList
- New field
- Changes to
GET /api/v3/account- New field
requireSelfTradePreventionwill appear in the response.
- New field
- New field
workingTime, indicating when the order started working on the order book, will appear in the following endpoints:POST /api/v3/orderGET /api/v3/orderPOST /api/v3/order/cancelReplacePOST /api/v3/order/ocoGET /api/v3/orderGET /api/v3/openOrdersGET /api/v3/allOrders
- Field
trailingTime, indicating the time when the trailing order is active and tracking price changes, will appear for the following order types (TAKE_PROFIT,TAKE_PROFIT_LIMIT,STOP_LOSS,STOP_LOSS_LIMITiftrailingDeltaparameter was provided) for the following endpoints:POST /api/v3/orderGET /api/v3/orderGET /api/v3/openOrdersGET /api/v3/allOrdersPOST /api/v3/order/cancelReplaceDELETE /api/v3/order
- Field
commissionRateswill appear in theGET /api/v3/acccountresponse
USER DATA STREAM
- eventType
executionReporthas new fieldsV-selfTradePreventionModeD-trailing_time(Appears if the trailing stop order is active)W-workingTime(Appears ifisWorking=true)
- Added a new market data base URL
https://data.binance.com. - Added a new WebSocket URL
wss://data-stream.binance.com.
Scheduled changes to the removal of !bookTicker around November 2022.
- The All Book Tickers stream (
!bookTicker) is set to be removed in November 2022. - More details of the actual removal date will be announced at a later time.
- Please use the Individual Book Ticker Streams instead. (
<symbol>@bookTicker). - Multiple
<symbol>@bookTickerstreams can be subscribed to over one connection.- Example: wss://stream.binance.com:9443/stream?streams=btcusdt@bookTicker/bnbbtc@bookTicker
Note that these are rolling changes, so it may take a few days for it to rollout to all our servers.
- Changes to
GET /api/v3/exchangeInfo- New optional parameter
permissionsadded to display all symbols with the permissions matching the parameter provided. (eg.SPOT,MARGIN) - If not provided, the default value will be
["SPOT","MARGIN","LEVERAGED"].- This means the request
GET /api/v3/exchangeInfowithout any parameters will show all symbols that can be used forSPOT,MARGIN, and/orLEVERAGEDtrading. - To search for symbols that can be traded on other permissions (e.g.
TRD_GRP_004, etc), then this needs to be searched for explicitly. (e.g.permissions=TRD_GRP_004)
- This means the request
- Cannot be combined with
symbolorsymbols
- New optional parameter
Note that these are rolling changes, so it may take a few days for it to rollout to all our servers.
- Changes to
GET /api/v3/tickerandGET /api/v3/ticker/24hr- New optional parameter
typeadded - Supported values for parameter
typeareFULLandMINIFULLis the default value and the response that is currently being returned from the endpointMINIomits the following fields from the response:priceChangePercent,weightedAvgPrice,bidPrice,bidQty,askPrice,askQty, andlastQty
- New optional parameter
- New error code
-1008- This is sent whenever the servers are overloaded with requests.
- New field
brokeredhas been added toGET /api/v3/account - New kline interval:
1s - New endpoint added:
GET /api/v3/uiKlines
REST API
- Changes to
POST /api/v3/orderandPOST /api/v3/order/cancelReplace- New optional fields
strategyIdandstrategyTypestrategyIdis a parameter used to identify an order as part of a strategy.strategyTypeis a parameter used to identify what strategy was running. (E.g. If all the orders are part of spot grid strategy, it can be set tostrategyType=1000000)- Note that the minimum value allowed for
strategyTypeis1000000.
- Note that the minimum value allowed for
- New optional fields
- Changes to
POST /api/v3/order/oco- New optional fields
limitStrategyId,limitStrategyType,stopStrategyId,stopStrategyType - These are the strategy metadata parameters for both legs of the OCO orders.
limitStrategyTypeandstopStrategyTypeboth cannot be less than1000000.
- New optional fields
- Changes to
GET /api/v3/order,GET /api/v3/openOrders, andGET /api/v3/allOrders- New fields
strategyIdandstrategyTypewill appear in the response JSON for orders that had these fields populated upon order placement.
- New fields
- Changes to
DELETE /api/v3/orderandDELETE /api/v3/openOrders- New fields
strategyIdandstrategyTypewill appear in the response JSON for cancelled orders that had these fields populated upon order placement.
- New fields
USER DATA STREAM
- New fields to eventType
executionReportjforstrategyIdJforstrategyType- Note that these fields only appear if these were populated upon order placement.
Changes to GET /api/v3/ticker
- Weight has been reduced from 5 to 2 per symbol, regardless of
windowSize. - The max number of symbols that can be processed in a request is 100.
- If the number of
symbolssent is more than 100, the error will be as follows:
{ "code": -1101, "msg": "Too many values sent for parameter 'symbols', maximum allowed up to 100." } - If the number of
- The max Weight for this endpoint will cap at 100.
- I.e. If the request has more than 50 symbols, the Weight will still be 100, regardless of
windowSize.
- I.e. If the request has more than 50 symbols, the Weight will still be 100, regardless of
Note: The update is being rolled out over the next few days, so these changes may not be visible right away.
SPOT API
GET /api/v3/tickeradded- Rolling window price change statistics based on
windowSizeprovided. - Contrary to
GET /api/v3/ticker/24hrthe list of symbols cannot be omitted. - If
windowSizenot specified, the value will default to1d. - Response is similar to
GET /api/v3/ticker/24hr, minus the following fields:prevClosePrice,lastQty,bidPrice,bidQty,askPrice,askQty
- Rolling window price change statistics based on
GET /api/v3/exchangeInforeturns new fieldcancelReplaceAllowedinsymbolslist.POST /api/v3/order/cancelReplaceadded- Cancels an existing order and places a new order on the same symbol.
- The filters are evaluated before the cancel order is placed.
- e.g. If the
MAX_NUM_ORDERSfilter is 10, and the total number of open orders on the account is also 10, when usingPOST /api/v3/order/cancelReplaceboth the cancel order placement and new order will fail because of the filter.
- e.g. If the
- The change is being rolled out in the next few days, thus this feature will be enabled once the upgrade is completed.
- New filter
NOTIONALhas been added.- Defines the allowed notional value (
price * quantity) based on a configuredminNotionalandmaxNotional
- Defines the allowed notional value (
- New exchange filter
EXCHANGE_MAX_NUM_ICEBERG_ORDERShas been added.- Defines the limit of open iceberg orders on an account
-
Changes to Order Book Depth Levels
- Quantities in the Depth levels were returning negative values in situations where they were exceeding the max value, resulting in an overflow.
- Going forward depth levels will not overflow, but will be capped at the max value based on the precision of the base asset. This means that the depth level is at max value or more.
- E.g. If the precision is 8, then the max value for quantity will be at 92,233,720,368.54775807.
- When the fix has been applied, a change in the order book at the affected price level is required for the changes to be visible.
-
What does this affect?
- SPOT API
GET /api/v3/depth
- Websocket Streams
<symbol>@depth<symbol>@depth@100ms<symbol>@depth<levels><symbol>@depth<levels>@100ms
- SPOT API
-
Updates to
MAX_POSITION- If an order's
quantitycan cause the position to overflow, this will now fail theMAX_POSITIONfilter.
- If an order's
- Changes to GET
api/v3/aggTrades- When providing
startTimeandendTime, the oldest items are returned.
- When providing
- Changed error messaging on
GET /api/v3/myTradeswhere parametersymbolis not provided:
{
"code": -1102,
"msg": "Mandatory parameter 'symbol' was not sent, was empty/null, or malformed."
}- The following endpoints now support multi-symbol querying using the parameter
symbols.GET /api/v3/ticker/24hrGET /api/v3/ticker/priceGET /api/v3/ticker/bookTicker
- In the above, the request weight will depend on the number of symbols provided in
symbols.
Please refer to the table below:
| Endpoint | Number of Symbols | Weight |
|---|---|---|
GET /api/v3/ticker/price |
Any | 2 |
GET /api/v3/ticker/bookTicker |
Any | 2 |
GET /api/v3/ticker/24hr |
1-20 | 1 |
GET /api/v3/ticker/24hr |
21-100 | 20 |
GET /api/v3/ticker/24hr |
101 or more | 40 |
REST API
- Trailing Stops have been enabled.
- This is a type of algo order where the activation is based on a percentage of a price change in the market using the new parameter
trailingDelta. - This can only used with any of the following order types:
STOP_LOSS,STOP_LOSS_LIMIT,TAKE_PROFIT,TAKE_PROFIT_LIMIT. - The
trailingDeltaparameter will be done in Basis Points or BIPS.- For example: a STOP_LOSS SELL order with a
trailingDeltaof 100 will trigger after a price decrease of 1% from the highest price after the order is placed. (100 / 10,000 => 0.01 => 1%)
- For example: a STOP_LOSS SELL order with a
- When used in combination with OCO Orders, the
trailingDeltawill determine when the contingent leg of the OCO will trigger. - When
trailingDeltais used in combination withstopPrice, once thestopPricecondition is met, the trailing stop starts tracking the price change from thestopPricebased on thetrailingDeltaprovided. - When no
stopPriceis sent, the trailing stop starts tracking the price changes from the last price based on thetrailingDeltaprovided.
- This is a type of algo order where the activation is based on a percentage of a price change in the market using the new parameter
- Changes to POST
/api/v3/order- New optional field
trailingDelta
- New optional field
- Changes to POST
/api/v3/order/test- New optional field
trailingDelta
- New optional field
- Changes to POST
/api/v3/order/oco- New optional field
trailingDelta
- New optional field
- A new filter
TRAILING_DELTAhas been added.- This filter is defined by the minimum and maximum values for the
trailingDeltavalue.
- This filter is defined by the minimum and maximum values for the
USER DATA STREAM
- New field in
executionReport- "d" for
trailingDelta
- "d" for
Note: The changes are being rolled out during the next few days, so these will not appear right away.
- Error message changed on
GET api/v3/allOrderswheresymbolis not provided:{ "code": -1102, "msg": "Mandatory parameter 'symbol' was not sent, was empty/null, or malformed." } - Fixed a typo with an error message when an account has disabled permissions (e.g. to withdraw, to trade, etc)
"This action is disabled on this account." - During a market data audit, we detected some issues with the Spot aggregate trade data.
- Missing aggregate trades were recovered.
- Duplicated records were marked invalid with the following values:
- p = '0' // price
- q = '0' // qty
- f = -1 // first_trade_id
- l = -1 // last_trade_id
- New field
allowTrailingStophas been added toGET /api/v3/exchangeInfo
(price-minPrice) % tickSize == 0rule inPRICE_FILTERhas been changed toprice % tickSize == 0.- A new filter
PERCENT_PRICE_BY_SIDEhas been added. - Changes to GET
api/v3/depth- The
limitvalue can be outside of the previous values (i.e. 5, 10, 20, 50, 100, 500, 1000,5000) and will return the correct limit. (i.e. if limit=3 then the response will be the top 3 bids and asks) - The limit still cannot exceed 5000. If the limit provided is greater than 5000, then the response will be truncated to 5000.
- Due to the changes, these are the updated request weights based on the limit value provided:
- The
| Limit | Request Weight |
|---|---|
| 1-100 | 1 |
| 101-500 | 5 |
| 501-1000 | 10 |
| 1001-5000 | 50 |
- Changes to GET
api/v3/aggTrades- When providing
startTimeandendTime, the oldest items are returned.
- When providing
- Removed out dated "Symbol Type" enum; added "Permissions" enum.
GET /api/v3/rateLimit/orderadded- The endpoint will display the user's current order count usage for all intervals.
- This endpoint will have a request weight of 20.
- Add a YAML file with OpenApi specification on the RESTful API.
- GET
api/v3/myTradeshas a new optional fieldorderId
- Added
Data Sourcein the documentation to explain where each endpoint is retrieving its data. - Added field
Data Sourceto each API endpoint in the documentation - GET
api/v3/exchangeInfonow supports single or multi-symbol query
On April 28, 2021 00:00 UTC the weights to the following endpoints will be adjusted:
GET /api/v3/orderweight increased to 2GET /api/v3/openOrdersweight increased to 3GET /api/v3/allOrdersweight increased to 10GET /api/v3/orderListweight increased to 2GET /api/v3/openOrderListweight increased to 3GET /api/v3/accountweight increased to 10GET /api/v3/myTradesweight increased to 10GET /api/v3/exchangeInfoweight increased to 10
USER DATA STREAM
outboundAccountInfohas been removed.
New API clusters have been added in order to improve performance.
Users can access any of the following API clusters, in addition to api.binance.com
If there are any performance issues with accessing api.binance.com please try any of the following instead:
- https://api1.binance.com/api/v3/*
- https://api2.binance.com/api/v3/*
- https://api3.binance.com/api/v3/*
USER DATA STREAM
outboundAccountInfohas been deprecated.outboundAccountInfowill be removed in the future. (Exact date unknown) Please useoutboundAccountPositioninstead.outboundAccountInfowill now only show the balance of non-zero assets and assets that have been reduced to 0.
- From 2020-05-01 UTC 00:00, all symbols will have a limit of 200 open orders using the MAX_NUM_ORDERS filter.
- No existing orders will be removed or canceled.
- Accounts that have 200 or more open orders on a symbol will not be able to place new orders on that symbol until the open order count is below 200.
- OCO orders count as 2 open orders before the
LIMITorder is touched or theSTOP_LOSS(orSTOP_LOSS_LIMIT) order is triggered; once this happens the other order is canceled and will no longer count as an open order.
- New field
permissions- Defines the trading permissions that are allowed on accounts and symbols.
permissionsis an enum array; values:SPOTMARGIN
permissionswill replaceisSpotTradingAllowedandisMarginTradingAllowedonGET api/v3/exchangeInfoin future API versions (v4+).- For an account to trade on a symbol, the account and symbol must share at least 1 permission in common.
- Updates to
GET api/v3/exchangeInfo- New field
permissionsadded. - New field
quoteAssetPrecisionadded; a duplicate of thequotePrecisionfield.quotePrecisionwill be removed in future API versions (v4+).
- New field
- Updates to
GET api/v3/account- New field
permissionsadded.
- New field
- New endpoint
DELETE api/v3/openOrders- This will allow a user to cancel all open orders on a single symbol.
- This endpoint will cancel all open orders including OCO orders.
- Orders can be canceled via the API on symbols in the
BREAKorHALTstatus.
OutboundAccountInfohas new fieldPwhich shows the trading permissions of the account.
WEB SOCKET STREAM
- WebSocket connections have a limit of 5 incoming messages per second. A message is considered:
- A PING frame
- A PONG frame
- A JSON control message (e.g. subscribe, unsubscribe)
- A connection that goes beyond the limit will be disconnected; IPs that are repeatedly disconnected may be banned.
- A single connection can listen to a maximum of 1024 streams.
MAX_POSITIONfilter added.-
This filter defines the allowed maximum position an account can have on the base asset of a symbol. An account's position defined as the sum of the account's:
- free balance of the base asset
- locked balance of the base asset
- sum of the qty of all open BUY orders
-
BUYorders will be rejected if the account's position is greater than the maximum position allowed.
-
- Quote Order Qty Market orders have been enabled on all symbols.
- Quote Order Qty
MARKETorders allow a user to specify the totalquoteOrderQtyspent or received in theMARKETorder. - Quote Order Qty
MARKETorders will not breakLOT_SIZEfilter rules; the order will execute a quantity that will have the notional value as close as possible toquoteOrderQty. - Using
BNBBTCas an example:- On the
BUYside, the order will buy as many BNB asquoteOrderQtyBTC can. - On the
SELLside, the order will sell as much BNB as needed to receivequoteOrderQtyBTC.
- On the
- Quote Order Qty
- api/v3/exchangeInfo has new fields:
quoteOrderQtyMarketAllowedbaseCommissionDecimalPlacesquoteCommissionDecimalPlaces
MARKETorders have a new optional field:quoteOrderQtyused to specify the quote quantity to BUY or SELL. This cannot be used in combination withquantity.- The exact timing that
quoteOrderQtyMARKET orders will be enabled is TBD. There will be a separate announcement and further details at that time.
- The exact timing that
- All order query endpoints will return a new field
origQuoteOrderQtyin the JSON payload. (e.g. GET api/v3/allOrders) - Updated error messages for -1128
- Sending an
OCOwith astopLimitPricebut without astopLimitTimeInForcewill return the error:
{ "code": -1128, "msg": "Combination of optional parameters invalid. Recommendation: 'stopLimitTimeInForce' should also be sent." } - Sending an
- Updated error messages for -1003 to specify the limit is referring to the request weight, not to the number of requests.
Deprecation of v1 endpoints:
By end of Q1 2020, the following endpoints will be removed from the API. The documentation has been updated to use the v3 versions of these endpoints.
- GET api/v1/depth
- GET api/v1/historicalTrades
- GET api/v1/aggTrades
- GET api/v1/klines
- GET api/v1/ticker/24hr
- GET api/v1/ticker/price
- GET api/v1/exchangeInfo
- POST api/v1/userDataStream
- PUT api/v1/userDataStream
- GET api/v1/ping
- GET api/v1/time
- GET api/v1/ticker/bookTicker
These endpoints however, will NOT be migrated to v3. Please use the following endpoints instead moving forward.
| Old V1 Endpoints | New V3 Endpoints |
|---|---|
| GET api/v1/ticker/allPrices | GET api/v3/ticker/price |
| GET api/v1/ticker/allBookTickers | GET api/v3/ticker/bookTicker |
-
Changes to
executionReportevent- If the C field is empty, it will now properly return
null, instead of"null". - New field Q which represents the
quoteOrderQty.
- If the C field is empty, it will now properly return
-
balanceUpdateevent type added- This event occurs when funds are deposited or withdrawn from your account.
- WSS now supports live subscribing/unsubscribing to streams.
- New WebSocket streams for bookTickers added:
<symbol>@bookTickerand!bookTicker. Seeweb-socket-streams.mdfor details.
- Faster order book data with 100ms updates:
<symbol>@depth@100msand<symbol>@depth#@100ms - Added "Update Speed:" to
web-socket-streams.md - Removed deprecated v1 endpoints as per previous announcement:
- GET api/v1/order
- GET api/v1/openOrders
- POST api/v1/order
- DELETE api/v1/order
- GET api/v1/allOrders
- GET api/v1/account
- GET api/v1/myTrades
- GET api/v1/depth
limitof 10000 has been temporarily removed
-
In Q4 2017, the following endpoints were deprecated and removed from the API documentation. They have been permanently removed from the API as of this version. We apologize for the omission from the original changelog:
- GET api/v1/order
- GET api/v1/openOrders
- POST api/v1/order
- DELETE api/v1/order
- GET api/v1/allOrders
- GET api/v1/account
- GET api/v1/myTrades
-
Streams, endpoints, parameters, payloads, etc. described in the documents in this repository are considered official and supported. The use of any other streams, endpoints, parameters, or payloads, etc. is not supported; use them at your own risk and with no guarantees.
-
New order type: OCO ("One Cancels the Other")
-
An OCO has 2 orders: (also known as legs in financial terms)
STOP_LOSSorSTOP_LOSS_LIMITlegLIMIT_MAKERleg
-
Price Restrictions:
SELL Orders: Limit Price > Last Price > Stop PriceBUY Orders: Limit Price < Last Price < Stop Price- As stated, the prices must "straddle" the last traded price on the symbol. EX: If the last price is 10:
- A SELL OCO must have the limit price greater than 10, and the stop price less than 10.
- A BUY OCO must have a limit price less than 10, and the stop price greater than 10.
-
Quantity Restrictions:
- Both legs must have the same quantity.
ICEBERGquantities however, do not have to be the same.
-
Execution Order:
- If the
LIMIT_MAKERis touched, the limit maker leg will be executed first BEFORE canceling the Stop Loss Leg. - if the Market Price moves such that the
STOP_LOSSorSTOP_LOSS_LIMITwill trigger, the Limit Maker leg will be canceled BEFORE executing theSTOP_LOSSLeg.
- If the
-
Canceling an OCO
- Canceling either order leg will cancel the entire OCO.
- The entire OCO can be canceled via the
orderListIdor thelistClientOrderId.
-
New Enums for OCO:
ListStatusTypeRESPONSE- used when ListStatus is responding to a failed action. (either order list placement or cancellation)EXEC_STARTED- used when an order list has been placed or there is an update to a list's status.ALL_DONE- used when an order list has finished executing and is no longer active.
ListOrderStatusEXECUTING- used when an order list has been placed or there is an update to a list's status.ALL_DONE- used when an order list has finished executing and is no longer active.REJECT- used when ListStatus is responding to a failed action. (either order list placement or cancellation)
ContingencyTypeOCO- specifies the type of order list.
-
New Endpoints:
- POST api/v3/order/oco
- DELETE api/v3/orderList
- GET api/v3/orderList
-
-
recvWindowcannot exceed 60000. -
New
intervalLettervalues for headers:- SECOND => S
- MINUTE => M
- HOUR => H
- DAY => D
-
New Headers
X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter)will give your current used request weight for the (intervalNum)(intervalLetter) rate limiter. For example, if there is a one minute request rate weight limiter set, you will get aX-MBX-USED-WEIGHT-1Mheader in the response. The legacy headerX-MBX-USED-WEIGHTwill still be returned and will represent the current used weight for the one minute request rate weight limit. -
New Header
X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter)that is updated on any valid order placement and tracks your current order count for the interval; rejected/unsuccessful orders are not guaranteed to haveX-MBX-ORDER-COUNT-**headers in the response.- Eg.
X-MBX-ORDER-COUNT-1Sfor "orders per 1 second" andX-MBX-ORDER-COUNT-1Dfor orders per "one day"
- Eg.
-
GET api/v1/depth now supports
limit5000 and 10000; weights are 50 and 100 respectively. -
GET api/v1/exchangeInfo has a new parameter
ocoAllowed.
executionReportevent now contains "g" which has theorderListId; it will be set to -1 for non-OCO orders.- New Event Type
listStatus;listStatusis sent on an update to any OCO order. - New Event Type
outboundAccountPosition;outboundAccountPositionis sent any time an account's balance changes and contains the assets that could have changed by the event that generated the balance change (a deposit, withdrawal, trade, order placement, or cancellation).
- -1131 BAD_RECV_WINDOW
recvWindowmust be less than 60000
- -1099 Not found, authenticated, or authorized
- This replaces error code -1999
- OCO_BAD_ORDER_PARAMS
- A parameter for one of the orders is incorrect.
- OCO_BAD_PRICES
- The relationship of the prices for the orders is not correct.
- UNSUPPORTED_ORD_OCO
- OCO orders are not supported for this symbol.
- X-MBX-USED-WEIGHT header added to Rest API responses.
- Retry-After header added to Rest API 418 and 429 responses.
- When canceling the Rest API can now return
errorCode-1013 OR -2011 if the symbol'sstatusisn'tTRADING. api/v1/depthno longer has the ignored and empty[].api/v3/myTradesnow returnsquoteQty; the price * qty of for the trade.
<symbol>@depthand<symbol>@depthXstreams no longer have the ignored and empty[].
- Matching Engine stability/reliability improvements.
- Rest API performance improvements.
- Can now cancel orders through the Rest API during a trading ban.
- New filters:
PERCENT_PRICE,MARKET_LOT_SIZE,MAX_NUM_ICEBERG_ORDERS. - Added
RAW_REQUESTSrate limit. Limits based on the number of requests over X minutes regardless of weight. - /api/v3/ticker/price increased to weight of 2 for a no symbol query.
- /api/v3/ticker/bookTicker increased weight of 2 for a no symbol query.
- DELETE /api/v3/order will now return an execution report of the final state of the order.
MIN_NOTIONALfilter has two new parameters:applyToMarket(whether or not the filter is applied to MARKET orders) andavgPriceMins(the number of minutes over which the price averaged for the notional estimation).intervalNumadded to /api/v1/exchangeInfo limits.intervalNumdescribes the amount of the interval. For example:intervalNum5, withintervalminute, means "every 5 minutes".
-
(qty * price) of all trades / sum of qty of all trades over previous 5 minutes.
-
If there is no trade in the last 5 minutes, it takes the first trade that happened outside of the 5min window. For example if the last trade was 20 minutes ago, that trade's price is the 5 min average.
-
If there is no trade on the symbol, there is no average price and market orders cannot be placed. On a new symbol with
applyToMarketenabled on theMIN_NOTIONALfilter, market orders cannot be placed until there is at least 1 trade. -
The current average price can be checked here:
https://api.binance.com/api/v3/avgPrice?symbol=<symbol>For example: https://api.binance.com/api/v3/avgPrice?symbol=BNBUSDT
Last quote asset transacted quantity(as variableY) added to execution reports. Represents thelastPrice*lastQty(L*l).
- New filter:
ICEBERG_PARTS POST api/v3/ordernew defaults fornewOrderRespType.ACK,RESULT, orFULL;MARKETandLIMITorder types default toFULL, all other orders default toACK.- POST api/v3/order
RESULTandFULLresponses now havecummulativeQuoteQty - GET api/v3/openOrders with no symbol weight reduced to 40.
- GET api/v3/ticker/24hr with no symbol weight reduced to 40.
- Max amount of trades from GET /api/v1/trades increased to 1000.
- Max amount of trades from GET /api/v1/historicalTrades increased to 1000.
- Max amount of aggregate trades from GET /api/v1/aggTrades increased to 1000.
- Max amount of aggregate trades from GET /api/v1/klines increased to 1000.
- Rest API Order lookups now return
updateTimewhich represents the last time the order was updated;timeis the order creation time. - Order lookup endpoints will now return
cummulativeQuoteQty. IfcummulativeQuoteQtyis < 0, it means the data isn't available for this order at this time. REQUESTSrate limit type changed toREQUEST_WEIGHT. This limit was always logically request weight and the previous name for it caused confusion.
cummulativeQuoteQtyfield added to order responses and execution reports (as variableZ). Represents the cummulative amount of thequotethat has been spent (with aBUYorder) or received (with aSELLorder). Historical orders will have a value < 0 in this field indicating the data is not available at this time.cummulativeQuoteQtydivided bycummulativeQtywill give the average price for an order.O(order creation time) added to execution reports
- GET /api/v1/historicalTrades weight decreased to 5
- GET /api/v1/aggTrades weight decreased to 1
- GET /api/v1/klines weight decreased to 1
- GET /api/v1/ticker/24hr all symbols weight decreased to number of trading symbols / 2
- GET /api/v3/allOrders weight decreased to 5
- GET /api/v3/myTrades weight decreased to 5
- GET /api/v3/account weight decreased to 5
- GET /api/v1/depth limit=500 weight decreased to 5
- GET /api/v1/depth limit=1000 weight decreased to 10
- -1003 error message updated to direct users to websockets
- GET /api/v1/ticker/24hr single symbol weight decreased to 1
- GET /api/v3/openOrders all symbols weight decreased to number of trading symbols / 2
- GET /api/v3/allOrders weight decreased to 15
- GET /api/v3/myTrades weight decreased to 15
- GET /api/v3/order weight decreased to 1
- myTrades will now return both sides of a self-trade/wash-trade
- GET /api/v1/aggTrades weight changed to 2
- GET /api/v1/klines weight changed to 2
- GET /api/v3/order weight changed to 2
- GET /api/v3/allOrders weight changed to 20
- GET /api/v3/account weight changed to 20
- GET /api/v3/myTrades weight changed to 20
- GET /api/v3/historicalTrades weight changed to 20