Author SHA1 Message Date
discountry 73d34434b0 fix size 2026-02-04 13:25:21 +08:00
599 changed files with 237 additions and 97980 deletions
+1 -16
View File
@@ -2,23 +2,12 @@
LANG=zh
# Exchange selection
EXCHANGE=aster # Pick aster (default) or binance/standx/grvt/lighter/backpack/paradex/nado
EXCHANGE=aster # Pick aster (default) or standx/grvt/lighter/backpack/paradex/nado
# Aster API credentials
ASTER_API_KEY=
ASTER_API_SECRET=
# Binance API credentials (set when EXCHANGE=binance)
BINANCE_API_KEY=
BINANCE_API_SECRET=
BINANCE_SYMBOL=BTCUSDT # Trading symbol. Use BTCUSDT_PERP to force perpetual when ambiguous.
BINANCE_MARKET_TYPE=perp # perp | spot | auto
# BINANCE_SANDBOX=false
# BINANCE_SPOT_REST_URL=https://api.binance.com
# BINANCE_FUTURES_REST_URL=https://fapi.binance.com
# BINANCE_SPOT_WS_URL=wss://stream.binance.com:9443/ws
# BINANCE_FUTURES_WS_URL=wss://fstream.binance.com/ws
# StandX authentication (set when EXCHANGE=standx)
STANDX_TOKEN=
STANDX_SYMBOL=BTC-USD
@@ -70,10 +59,6 @@ MAKER_REFRESH_INTERVAL_MS=500 # Maker refresh cadence (ms)
MAKER_MAX_CLOSE_SLIPPAGE_PCT=0.05 # Maker close slippage guard (fallbacks to MAX_CLOSE_SLIPPAGE_PCT)
MAKER_PRICE_TICK=0.1 # Maker price tick size (defaults to PRICE_TICK)
# Maker-points Binance depth imbalance monitor
MAKER_POINTS_BINANCE_DEPTH_WINDOW_BPS=3 # Binance depth monitor window around best bid/ask (bps)
MAKER_POINTS_BINANCE_DEPTH_IMBALANCE_RATIO=9 # Imbalance threshold ratio (e.g. 9 => one side >= 9x)
# Grid strategy defaults
GRID_LOWER_PRICE=25000 # Grid lower bound price (quote currency)
GRID_UPPER_PRICE=35000 # Grid upper bound price
+1 -33
View File
@@ -86,7 +86,7 @@ curl -fsSL https://github.com/discountry/ritmex-bot/raw/refs/heads/main/setup.sh
| 变量 | 说明 |
| --- | --- |
| `EXCHANGE` | 选择交易所(`aster`/`binance`/`standx`/`grvt`/`lighter`/`backpack`/`paradex`/`nado` |
| `EXCHANGE` | 选择交易所(`aster`/`standx`/`grvt`/`lighter`/`backpack`/`paradex`/`nado` |
| `TRADE_SYMBOL` | 交易对(默认 `BTCUSDT` |
| `TRADE_AMOUNT` | 单笔下单数量(标的资产计) |
| `LOSS_LIMIT` | 单笔最大亏损触发的强平额度(USDT) |
@@ -111,38 +111,6 @@ curl -fsSL https://github.com/discountry/ritmex-bot/raw/refs/heads/main/setup.sh
3. 根据交易对调整 `TRADE_SYMBOL`、`PRICE_TICK`、`QTY_STEP` 等精度参数。
4. 一键脚本会自动写入这些变量,手动部署时需自行维护。
### Binance
1. 设置 `EXCHANGE=binance`。
2. 填写 `BINANCE_API_KEY`、`BINANCE_API_SECRET`。
3. 设置市场模式 `BINANCE_MARKET_TYPE`
- `perp`:永续(默认)
- `spot`:现货
- `auto`:按符号自动匹配(同名现货/永续并存时建议不要使用)
4. 设置交易符号 `BINANCE_SYMBOL`(或使用 `TRADE_SYMBOL`):
- 永续建议写 `BTCUSDT_PERP`(或直接 `BTCUSDT` + `BINANCE_MARKET_TYPE=perp`
- 现货建议写 `BTCUSDT`(也支持 `BTCUSDT_SPOT`
5. 需要做期现套利(Basis)时,建议显式拆分:
- `BASIS_FUTURES_SYMBOL=BTCUSDT_PERP`
- `BASIS_SPOT_SYMBOL=BTCUSDT`
6. 可选测试网/自定义端点:
- `BINANCE_SANDBOX=true`
- `BINANCE_SPOT_REST_URL` / `BINANCE_FUTURES_REST_URL`
- `BINANCE_SPOT_WS_URL` / `BINANCE_FUTURES_WS_URL`
> Binance 适配器默认优先使用 WebSocket(盘口、ticker、kline、账户/订单用户流),仅在必要时使用 REST 补偿与兜底。
>
> 若使用现货模式,部分“仅合约可用”的保护单能力会受交易所限制,策略会按交易所能力自动降级。
**示例(永续做市)**
```bash
EXCHANGE=binance BINANCE_MARKET_TYPE=perp BINANCE_SYMBOL=BTCUSDT_PERP bun run index.ts --strategy maker
```
**示例(现货网格)**
```bash
EXCHANGE=binance BINANCE_MARKET_TYPE=spot BINANCE_SYMBOL=BTCUSDT bun run index.ts --strategy grid
```
### StandX
* [StandX 做市策略教程](docs/standx/maker-points-guide.md)
+1 -33
View File
@@ -82,7 +82,7 @@ The script installs Bun, project dependencies, collects Aster API credentials, g
| Variable | Purpose |
| --- | --- |
| `EXCHANGE` | Choose the venue (`aster` / `binance` / `standx` / `grvt` / `lighter` / `backpack` / `paradex` / `nado`) |
| `EXCHANGE` | Choose the venue (`aster` / `standx` / `grvt` / `lighter` / `backpack` / `paradex` / `nado`) |
| `TRADE_SYMBOL` | Contract symbol (defaults to `BTCUSDT`) |
| `TRADE_AMOUNT` | Order size in base asset units |
| `LOSS_LIMIT` | Max per-trade loss in USDT before forced close |
@@ -108,38 +108,6 @@ The script installs Bun, project dependencies, collects Aster API credentials, g
3. Adjust `TRADE_SYMBOL`, `PRICE_TICK`, and `QTY_STEP` to match the requested market.
4. The bootstrap script auto-populates these variables; manual installs must maintain them.
### Binance
1. Set `EXCHANGE=binance`.
2. Provide `BINANCE_API_KEY` and `BINANCE_API_SECRET`.
3. Set market mode via `BINANCE_MARKET_TYPE`:
- `perp`: perpetual futures (default)
- `spot`: spot market
- `auto`: resolve by symbol (not recommended when both spot/perp share the same symbol)
4. Set `BINANCE_SYMBOL` (or fallback to `TRADE_SYMBOL`):
- Perp recommended: `BTCUSDT_PERP` (or `BTCUSDT` with `BINANCE_MARKET_TYPE=perp`)
- Spot recommended: `BTCUSDT` (also accepts `BTCUSDT_SPOT`)
5. For Basis arbitrage on Binance, explicitly split legs:
- `BASIS_FUTURES_SYMBOL=BTCUSDT_PERP`
- `BASIS_SPOT_SYMBOL=BTCUSDT`
6. Optional sandbox/custom endpoints:
- `BINANCE_SANDBOX=true`
- `BINANCE_SPOT_REST_URL` / `BINANCE_FUTURES_REST_URL`
- `BINANCE_SPOT_WS_URL` / `BINANCE_FUTURES_WS_URL`
> The Binance adapter is WS-first by default (depth/ticker/kline/account/order streams), with REST used only for reconciliation and fallback.
>
> In spot mode, some derivatives-only protective order capabilities are exchange-limited, and the strategy will degrade gracefully based on venue capabilities.
**Example (perp maker)**
```bash
EXCHANGE=binance BINANCE_MARKET_TYPE=perp BINANCE_SYMBOL=BTCUSDT_PERP bun run index.ts --strategy maker
```
**Example (spot grid)**
```bash
EXCHANGE=binance BINANCE_MARKET_TYPE=spot BINANCE_SYMBOL=BTCUSDT bun run index.ts --strategy grid
```
### StandX
* [StandX Maker Points Strategy Guide](docs/standx/maker-points-guide.md)
File diff suppressed because it is too large Load Diff
@@ -1,9 +0,0 @@
---
title: "Terms of Use | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/PROD-TERMS-OF-USE"
fetched_at: "2026-02-26T10:38:06.668Z"
---
# SPOT Exchange Terms of Use
Binance products and services are subject to the [Product Terms of Use](https://www.binance.com/en/terms).
Please read it carefully before proceeding.
-255
View File
@@ -1,255 +0,0 @@
---
title: "Readme | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/README"
fetched_at: "2026-02-26T10:38:06.666Z"
---
# Official Documentation for the Binance APIs and Streams.
- Official Announcements regarding changes, downtime, etc. to the API and Streams will be reported here: **[https://t.me/binance\_api\_announcements](https://t.me/binance_api_announcements)**
- 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.**
Name
Description
[enums.md](https://developers.binance.com/docs/binance-spot-api-docs/enums)
Details on the enums used by REST and WebSocket API
[errors.md](https://developers.binance.com/docs/binance-spot-api-docs/errors)
Error codes and messages of Spot API
[filters.md](https://developers.binance.com/docs/binance-spot-api-docs/filters)
Details on the filters used by Spot API
[rest-api.md](https://developers.binance.com/docs/binance-spot-api-docs/rest-api)
Spot REST API (`/api`)
[web-socket-api.md](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api)
Spot WebSocket API
[fix-api.md](https://developers.binance.com/docs/binance-spot-api-docs/fix-api)
FIX API
[web-socket-streams.md](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Spot Market Data WebSocket streams
[sbe-market-data-streams.md](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
SBE Market Data Streams
[user-data-stream.md](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
Spot User Data WebSocket streams
[sbe\_schemas](https://developers.binance.com/docs/binance-spot-api-docs/sbe/schemas)
Spot Simple Binary Encoding (SBE) schemas
[testnet](https://developers.binance.com/docs/binance-spot-api-docs/testnet)
API docs for features available only on SPOT Testnet
[demo-mode](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode)
Page regarding Demo Mode
[Margin Trading](https://developers.binance.com/docs/margin_trading)
Details on Margin Trading
[Derivative UM Futures](https://developers.binance.com/docs/derivatives/usds-margined-futures/general-info)
Details on Derivative UM Futures (`/fapi`)
[Derivative CM Futures](https://developers.binance.com/docs/derivatives/coin-margined-futures/general-info)
Details on Derivative CM Futures (`/dapi`)
[Derivative Options](https://developers.binance.com/docs/derivatives/option/general-info)
Details on Derivative European Options (`/eapi`)
[Derivative Portfolio Margin](https://developers.binance.com/docs/derivatives/portfolio-margin/general-info)
Details on Derivative Portfolio Margin (`/papi`)
[Wallet](https://developers.binance.com/docs/wallet)
Details on Wallet endpoints (`/sapi`)
[Sub Account](https://developers.binance.com/docs/sub_account/general-info)
Details on Sub-Account requests (`/sapi`)
[Simple Earn](https://developers.binance.com/docs/simple_earn/general-info)
Details on Simple Earn
[Dual Investment](https://developers.binance.com/docs/dual_investment)
Details on Dual Investment
[Auto Invest](https://developers.binance.com/docs/auto_invest)
Details on Auto Invest
[Staking](https://developers.binance.com/docs/staking)
Details on Staking
[Mining](https://developers.binance.com/docs/mining)
Details on Mining
[Algo Trading](https://developers.binance.com/docs/algo)
Details on Algo Trading
[Copy Trading](https://developers.binance.com/docs/copy_trading)
Details on Copy Trading
[Portfolio Margin Pro](https://developers.binance.com/docs/derivatives/portfolio-margin-pro/general-info)
Details on Portfolio Margin Pro
[Fiat](https://developers.binance.com/docs/fiat)
Details on Fiat
[C2C](https://developers.binance.com/docs/c2c)
Details on C2C
[VIP Loan](https://developers.binance.com/docs/vip_loan)
Details on VIP Loan
[Crypto Loan](https://developers.binance.com/docs/crypto_loan)
Details on Crypto Loan
[Pay](https://developers.binance.com/docs/binance-pay)
Details on Binance Pay
[Convert](https://developers.binance.com/docs/convert)
Details on Convert API
[Rebate](https://developers.binance.com/docs/rebate)
Details on Spot Rebate
[NFT](https://developers.binance.com/docs/nft)
Details on NFT requests
[Gift Card](https://developers.binance.com/docs/gift_card)
Details on Gift Card API
### FAQ[](https://developers.binance.com/docs/binance-spot-api-docs/README)
Name
Description
[api\_key\_types](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
API Key Types
[spot\_glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
Definition of terms used in the API
[commission\_faq](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
Explaining commission calculations on the API
[trailing-stop-faq](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Detailed Information on the behavior of Trailing Stops on the API
[stp\_faq](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
Detailed Information on the behavior of Self Trade Prevention (aka STP) on the API
[market\_orders\_faq](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_orders_faq.md)
Detailed information on the behavior of Market Orders
[market-data-only](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only)
Information on our market data only API and WebSocket streams.
[sor\_faq](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
Smart Order Routing (SOR)
[order\_count\_decrement](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
Updates to the Spot Order Count Limit Rules.
[order\_amend\_keep\_priority](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Detailed Information on the behavior of Order Amend Keep Priority
[pegged\_orders](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Detailed Information on Pegged Orders
[sbe\_faq](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
Information on the implementation of Simple Binary Encoding (SBE) on the API
### Change log[](https://developers.binance.com/docs/binance-spot-api-docs/README)
Please refer to [CHANGELOG](https://developers.binance.com/docs/binance-spot-api-docs/CHANGELOG) for latest changes on our APIs and Streamers.
### Useful Resources[](https://developers.binance.com/docs/binance-spot-api-docs/README)
- [Postman Collections](https://github.com/binance/binance-api-postman)
- Postman collections are available, and they are recommended for new users seeking a quick and easy start with the API.
- Connectors
- The following are lightweight libraries that work as connectors to the Binance public API, written in different languages:
- [Python](https://github.com/binance/binance-connector-python)
- [Node.js](https://github.com/binance/binance-connector-node)
- [Ruby](https://github.com/binance/binance-connector-ruby)
- [DotNET C#](https://github.com/binance/binance-connector-dotnet)
- [Java](https://github.com/binance/binance-connector-java)
- [Rust](https://github.com/binance/binance-spot-connector-rust)
- [PHP](https://github.com/binance/binance-connector-php)
- [Go](https://github.com/binance/binance-connector-go)
- [TypeScript](https://github.com/binance/binance-connector-typescript)
- FIX Connector - This provides access to the exchange using the FIX protocol.
- [Python](https://github.com/binance/binance-fix-connector-python)
- [Swagger](https://github.com/binance/binance-api-swagger)
- A YAML file with OpenAPI specification for the RESTful API is available, along with a Swagger UI page for reference.
- [Spot Testnet](https://testnet.binance.vision/)
- Users can use the SPOT Testnet to practice SPOT trading.
- Currently, this is only available via the API.
- Only endpoints starting with `/api/*` are supported, `/sapi/*` is not supported.
### Contact Us[](https://developers.binance.com/docs/binance-spot-api-docs/README)
- [Binance API Telegram Group](https://t.me/binance_api_english)
- For any questions regarding sudden drop in performance with the API and/or WebSockets.
- For any general questions about the API not covered in the documentation.
- [Binance Developers](https://dev.binance.vision/)
- For any questions/help regarding code implementation with API and/or WebSockets.
- [Binance Customer Support](https://www.binance.com/en/support-center)
- For cases such as missing funds, help with 2FA, etc.
- [FAQ](https://developers.binance.com/docs/binance-spot-api-docs/README)
- [Change log](https://developers.binance.com/docs/binance-spot-api-docs/README)
- [Useful Resources](https://developers.binance.com/docs/binance-spot-api-docs/README)
- [Contact Us](https://developers.binance.com/docs/binance-spot-api-docs/README)
-16
View File
@@ -1,16 +0,0 @@
---
title: "Changelog | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/demo-mode"
fetched_at: "2026-02-26T10:38:06.839Z"
---
# CHANGELOG for Binance SPOT Demo Mode
**Last Updated: 2026-01-29**
### 2026-01-29[](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode)
This changelog will announce any scheduled downtime for maintenance for the SPOT Demo Mode environment.
For more information on how to use Demo Mode via API, please refer to the [General Info](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info) page.
- [2026-01-29](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode)
@@ -1,16 +0,0 @@
---
title: "Changelog | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/CHANGELOG"
fetched_at: "2026-02-26T10:38:06.898Z"
---
# CHANGELOG for Binance SPOT Demo Mode
**Last Updated: 2026-01-29**
### 2026-01-29[](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/CHANGELOG)
This changelog will announce any scheduled downtime for maintenance for the SPOT Demo Mode environment.
For more information on how to use Demo Mode via API, please refer to the [General Info](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info) page.
- [2026-01-29](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/CHANGELOG)
@@ -1,9 +0,0 @@
---
title: "Demo Mode Terms of Use | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/DEMO-TERMS-OF-USE"
fetched_at: "2026-02-26T10:38:06.921Z"
---
# SPOT Demo Mode Terms of Use
Binance products and services are subject to the [Product Terms of Use](https://www.binance.com/en/about-legal/terms-demo-trading).
Please read it carefully before proceeding.
@@ -1,148 +0,0 @@
---
title: "General Info | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info"
fetched_at: "2026-02-26T10:38:06.931Z"
---
# Demo Mode for SPOT Trading
This page explains how to use [Demo Mode Trading](https://www.binance.com/en/support/faq/detail/9be58f73e5e14338809e3b705b9687dd) via the API.
## How can I trade on Demo Mode using the API?[](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info)
1. After logging into your Binance account, click on Binance Demo Trading and then you can create an API key in the [API Key Management page](https://demo.binance.com/en/my/settings/api-management).
2. Follow the official documentation of the SPOT API, replacing the URLs of the endpoints/methods with the following values:
Service
Spot API URLs
Demo Mode URLs
REST API
- https://api.binance.com/api
- https://api-gcp.binance.com/api
- https://api1.binance.com/api
- https://api2.binance.com/api
- https://api3.binance.com/api
- https://api4.binance.com/api
- **https://demo-api.binance.com/api**
WebSocket API
- wss://ws-api.binance.com/ws-api/v3
- wss://ws-api.binance.com:9443/ws-api/v3
- **wss://demo-ws-api.binance.com/ws-api/v3**
WebSocket Market Streams
- wss://stream.binance.com/ws
- wss://stream.binance.com:9443/ws
- **wss://demo-stream.binance.com/ws**
- **wss://demo-stream.binance.com:9443/ws**
- wss://stream.binance.com/stream
- wss://stream.binance.com:9443/stream
- **wss://demo-stream.binance.com/stream**
- **wss://demo-stream.binance.com:9443/stream**
WebSocket Market Streams (SBE)
- wss://stream-sbe.binance.com/ws
- wss://stream-sbe.binance.com:9443/ws
- **wss://demo-stream-sbe.binance.com/ws**
- **wss://demo-stream-sbe.binance.com:9443/ws**
- wss://stream-sbe.binance.com/stream
- wss://stream-sbe.binance.com:9443/stream
- **wss://demo-stream-sbe.binance.com/stream**
- **wss://demo-stream-sbe.binance.com:9443/stream**
FIX
(Send FIX requests; receive FIX responses)
- tcp+tls://fix-oe.binance.com:9000
- **tcp+tls://demo-fix-oe.binance.com:9000**
- tcp+tls://fix-dc.binance.com:9000
- **tcp+tls://demo-fix-dc.binance.com:9000**
- tcp+tls://fix-md.binance.com:9000
- **tcp+tls://demo-fix-md.binance.com:9000**
FIX SBE
(Send FIX requests; receive FIX SBE responses)
- tcp+tls://fix-oe.binance.com:9001
- **tcp+tls://demo-fix-oe.binance.com:9001**
- tcp+tls://fix-dc.binance.com:9001
- **tcp+tls://demo-fix-dc.binance.com:9001**
- tcp+tls://fix-md.binance.com:9001
- **tcp+tls://demo-fix-md.binance.com:9001**
FIX SBE
(Send FIX SBE requests; receive FIX SBE responses)
- tcp+tls://fix-oe.binance.com:9002
- **tcp+tls://demo-fix-oe.binance.com:9002**
- tcp+tls://fix-dc.binance.com:9002
- **tcp+tls://demo-fix-dc.binance.com:9002**
- tcp+tls://fix-md.binance.com:9002
- **tcp+tls://demo-fix-md.binance.com:9002**
## What is the difference between SPOT Testnet and SPOT Demo Mode?[](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info)
SPOT Testnet
SPOT Demo Mode
Balances are reset every month.
You can reset your balance whenever you want via the UI.
SPOT Testnet sometimes has new features before the live exchange.
Demo Mode always has the same features as the live exchange.
Testnet's prices and order books are independent from the live exchange.
Demo Mode's prices and order books are similar to the live exchange.
IP Limits, Unfilled Order Count, Exchange Filters are generally the same as the live exchange.
IP Limits, Unfilled Order Count, Exchange Filters are exactly the same as the live exchange.
**In summary**:
- SPOT Testnet is useful to integrate with upcoming features not yet available on the live exchange.
- Demo Mode is useful to test against _realistic_ market data.
> \[!WARNING\] Realistic market data is not equal to "real" market data. Do not assume trading strategies that work in Demo Mode will work in the live exchange.
## What happens when Demo Mode is under maintenance?[](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info)
- There will be an announcement on the [CHANGELOG](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/CHANGELOG) page prior to downtime.
- During maintenance, you will not be able to place or cancel orders.
- [How can I trade on Demo Mode using the API?](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info)
- [What is the difference between SPOT Testnet and SPOT Demo Mode?](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info)
- [What happens when Demo Mode is under maintenance?](https://developers.binance.com/docs/binance-spot-api-docs/demo-mode/general-info)
-239
View File
@@ -1,239 +0,0 @@
---
title: "Enums | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/enums"
fetched_at: "2026-02-26T10:38:07.237Z"
---
# ENUM Definitions
This will apply for both REST API and WebSocket API.
## Symbol status (status)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `TRADING`
- `END_OF_DAY`
- `HALT`
- `BREAK`
## Account and Symbol Permissions (permissions)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `SPOT`
- `MARGIN`
- `LEVERAGED`
- `TRD_GRP_002`
- `TRD_GRP_003`
- `TRD_GRP_004`
- `TRD_GRP_005`
- `TRD_GRP_006`
- `TRD_GRP_007`
- `TRD_GRP_008`
- `TRD_GRP_009`
- `TRD_GRP_010`
- `TRD_GRP_011`
- `TRD_GRP_012`
- `TRD_GRP_013`
- `TRD_GRP_014`
- `TRD_GRP_015`
- `TRD_GRP_016`
- `TRD_GRP_017`
- `TRD_GRP_018`
- `TRD_GRP_019`
- `TRD_GRP_020`
- `TRD_GRP_021`
- `TRD_GRP_022`
- `TRD_GRP_023`
- `TRD_GRP_024`
- `TRD_GRP_025`
## Order status (status)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
Status
Description
`NEW`
The order has been accepted by the engine.
`PENDING_NEW`
The order is in a pending phase until the working order of an order list has been fully filled.
`PARTIALLY_FILLED`
A part of the order has been filled.
`FILLED`
The order has been completed.
`CANCELED`
The order has been canceled by the user.
`PENDING_CANCEL`
Currently unused
`REJECTED`
The order was not accepted by the engine and not processed.
`EXPIRED`
The order was canceled according to the order type's rules (e.g. LIMIT FOK orders with no fill, LIMIT IOC or MARKET orders that partially fill)
or by the exchange, (e.g. orders canceled during liquidation, orders canceled during maintenance)
`EXPIRED_IN_MATCH`
The order was expired by the exchange due to STP. (e.g. an order with `EXPIRE_TAKER` will match with existing orders on the book with the same account or same `tradeGroupId`)
## Order List Status (listStatusType)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
Status
Description
`RESPONSE`
This is used when the ListStatus is responding to a failed action. (E.g. order list placement or cancellation)
`EXEC_STARTED`
The order list has been placed or there is an update to the order list status.
`UPDATED`
The clientOrderId of an order in the order list has been changed.
`ALL_DONE`
The order list has finished executing and thus is no longer active.
## Order List Order Status (listOrderStatus)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
Status
Description
`EXECUTING`
Either an order list has been placed or there is an update to the status of the list.
`ALL_DONE`
An order list has completed execution and thus no longer active.
`REJECT`
The List Status is responding to a failed action either during order placement or order canceled.
## ContingencyType[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `OCO`
- `OTO`
## AllocationType[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `SOR`
## Order types (orderTypes, type)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `LIMIT`
- `MARKET`
- `STOP_LOSS`
- `STOP_LOSS_LIMIT`
- `TAKE_PROFIT`
- `TAKE_PROFIT_LIMIT`
- `LIMIT_MAKER`
## Order Response Type (newOrderRespType)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `ACK`
- `RESULT`
- `FULL`
## Working Floor[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `EXCHANGE`
- `SOR`
## Order side (side)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- `BUY`
- `SELL`
## Time in force (timeInForce)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
This sets how long an order will be active before expiration.
Status
Description
`GTC`
Good Til Canceled
An order will be on the book unless the order is canceled.
`IOC`
Immediate Or Cancel
An order will try to fill the order as much as it can before the order expires.
`FOK`
Fill or Kill
An order will expire if the full order cannot be filled upon execution.
## Rate limiters (rateLimitType)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- REQUEST\_WEIGHT
```
{ "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000}
```
- ORDERS
```
{ "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 1, "limit": 10}
```
- RAW\_REQUESTS
```
{ "rateLimitType": "RAW_REQUESTS", "interval": "MINUTE", "intervalNum": 5, "limit": 61000}
```
## Rate limit intervals (interval)[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- SECOND
- MINUTE
- DAY
## STP Modes[](https://developers.binance.com/docs/binance-spot-api-docs/enums)
Read [Self Trade Prevention (STP) FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq) to learn more.
- `NONE`
- `EXPIRE_MAKER`
- `EXPIRE_TAKER`
- `EXPIRE_BOTH`
- `DECREMENT`
- `TRANSFER`
- [Symbol status (status)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Account and Symbol Permissions (permissions)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Order status (status)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Order List Status (listStatusType)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Order List Order Status (listOrderStatus)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [ContingencyType](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [AllocationType](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Order types (orderTypes, type)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Order Response Type (newOrderRespType)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Working Floor](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Order side (side)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Time in force (timeInForce)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Rate limiters (rateLimitType)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [Rate limit intervals (interval)](https://developers.binance.com/docs/binance-spot-api-docs/enums)
- [STP Modes](https://developers.binance.com/docs/binance-spot-api-docs/enums)
-832
View File
@@ -1,832 +0,0 @@
---
title: "Error | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/errors"
fetched_at: "2026-02-26T10:38:07.185Z"
---
# Error codes for Binance
Errors consist of two parts: an error code and a message. Codes are universal, but messages can vary. Here is the error JSON payload:
```
{ "code": -1121, "msg": "Invalid symbol."}
```
## 10xx - General Server or Network issues[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
### \-1000 UNKNOWN[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- An unknown error occurred while processing the request.
### \-1001 DISCONNECTED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Internal error; unable to process your request. Please try again.
### \-1002 UNAUTHORIZED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- You are not authorized to execute this request.
### \-1003 TOO\_MANY\_REQUESTS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Too many requests queued.
- 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.
- Way too much request weight used; IP banned until %s. Please use WebSocket Streams for live updates to avoid bans.
### \-1006 UNEXPECTED\_RESP[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- An unexpected response was received from the message bus. Execution status unknown.
### \-1007 TIMEOUT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Timeout waiting for response from backend server. Send status unknown; execution status unknown.
### \-1008 SERVER\_BUSY[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Server is currently overloaded with other requests. Please try again in a few minutes.
### \-1013 INVALID\_MESSAGE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- The request is rejected by the API. (i.e. The request didn't reach the Matching Engine.)
- Potential error messages can be found in [Filter Failures](https://developers.binance.com/docs/binance-spot-api-docs/errors) or [Failures during order placement](https://developers.binance.com/docs/binance-spot-api-docs/errors).
### \-1014 UNKNOWN\_ORDER\_COMPOSITION[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Unsupported order combination.
### \-1015 TOO\_MANY\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Too many new orders.
- Too many new orders; current limit is %s orders per %s.
### \-1016 SERVICE\_SHUTTING\_DOWN[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This service is no longer available.
### \-1020 UNSUPPORTED\_OPERATION[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This operation is not supported.
### \-1021 INVALID\_TIMESTAMP[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Timestamp for this request is outside of the recvWindow.
- Timestamp for this request was 1000ms ahead of the server's time.
### \-1022 INVALID\_SIGNATURE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Signature for this request is not valid.
### \-1033 COMP\_ID\_IN\_USE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `SenderCompId(49)` is currently in use. Concurrent use of the same SenderCompId within one account is not allowed.
### \-1034 TOO\_MANY\_CONNECTIONS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Too many concurrent connections; current limit is '%s'.
- Too many connection attempts for account; current limit is %s per '%s'.
- Too many connection attempts from IP; current limit is %s per '%s'.
### \-1035 LOGGED\_OUT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Please send [Logout`<5>`](https://developers.binance.com/docs/binance-spot-api-docs/fix-api) message to close the session.
## 11xx - Request issues[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
### \-1100 ILLEGAL\_CHARS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Illegal characters found in a parameter.
- Illegal characters found in parameter '%s'; legal range is '%s'.
### \-1101 TOO\_MANY\_PARAMETERS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Too many parameters sent for this endpoint.
- Too many parameters; expected '%s' and received '%s'.
- Duplicate values for a parameter detected.
### \-1102 MANDATORY\_PARAM\_EMPTY\_OR\_MALFORMED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A mandatory parameter was not sent, was empty/null, or malformed.
- Mandatory parameter '%s' was not sent, was empty/null, or malformed.
- Param '%s' or '%s' must be sent, but both were empty/null!
- Required tag '%s' missing.
- Field value was empty or malformed.
- '%s' contains unexpected value. Cannot be greater than %s.
### \-1103 UNKNOWN\_PARAM[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- An unknown parameter was sent.
- Undefined Tag.
### \-1104 UNREAD\_PARAMETERS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Not all sent parameters were read.
- Not all sent parameters were read; read '%s' parameter(s) but was sent '%s'.
### \-1105 PARAM\_EMPTY[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A parameter was empty.
- Parameter '%s' was empty.
### \-1106 PARAM\_NOT\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A parameter was sent when not required.
- Parameter '%s' sent when not required.
- A tag '%s' was sent when not required.
### \-1108 PARAM\_OVERFLOW[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Parameter '%s' overflowed.
### \-1111 BAD\_PRECISION[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Parameter '%s' has too much precision.
### \-1112 NO\_DEPTH[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- No orders on book for symbol.
### \-1114 TIF\_NOT\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- TimeInForce parameter sent when not required.
### \-1115 INVALID\_TIF[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid timeInForce.
### \-1116 INVALID\_ORDER\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid orderType.
### \-1117 INVALID\_SIDE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid side.
### \-1118 EMPTY\_NEW\_CL\_ORD\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- New client order ID was empty.
### \-1119 EMPTY\_ORG\_CL\_ORD\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Original client order ID was empty.
### \-1120 BAD\_INTERVAL[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid interval.
### \-1121 BAD\_SYMBOL[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid symbol.
### \-1122 INVALID\_SYMBOLSTATUS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid symbolStatus.
### \-1125 INVALID\_LISTEN\_KEY[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This listenKey does not exist.
### \-1127 MORE\_THAN\_XX\_HOURS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Lookup interval is too big.
- More than %s hours between startTime and endTime.
### \-1128 OPTIONAL\_PARAMS\_BAD\_COMBO[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Combination of optional parameters invalid.
- Combination of optional fields invalid. Recommendation: '%s' and '%s' must both be sent.
- Fields \[%s\] must be sent together or omitted entirely.
- Invalid `MDEntryType (269)` combination. BID and OFFER must be requested together.
- Conflicting fields: \['%s'...\]
### \-1130 INVALID\_PARAMETER[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid data sent for a parameter.
- Data sent for parameter '%s' is not valid.
### \-1134 BAD\_STRATEGY\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `strategyType` was less than 1000000.
- `TargetStrategy (847)` was less than 1000000.
### \-1135 INVALID\_JSON[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid JSON Request
- JSON sent for parameter '%s' is not valid
### \-1139 INVALID\_TICKER\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid ticker type.
### \-1145 INVALID\_CANCEL\_RESTRICTIONS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `cancelRestrictions` has to be either `ONLY_NEW` or `ONLY_PARTIALLY_FILLED`.
### \-1151 DUPLICATE\_SYMBOLS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Symbol is present multiple times in the list.
### \-1152 INVALID\_SBE\_HEADER[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid `X-MBX-SBE` header; expected `<SCHEMA_ID>:<VERSION>`.
- Invalid SBE message header.
### \-1153 UNSUPPORTED\_SCHEMA\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Unsupported SBE schema ID or version specified in the `X-MBX-SBE` header.
- Invalid SBE schema ID or version specified.
### \-1155 SBE\_DISABLED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- SBE is not enabled.
### \-1158 OCO\_ORDER\_TYPE\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Order type not supported in OCO.
- If the order type provided in the `aboveType` and/or `belowType` is not supported.
### \-1160 OCO\_ICEBERGQTY\_TIMEINFORCE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Parameter '%s' is not supported if `aboveTimeInForce`/`belowTimeInForce` is not GTC.
- If the order type for the above or below leg is `STOP_LOSS_LIMIT`, and `icebergQty` is provided for that leg, the `timeInForce` has to be `GTC` else it will throw an error.
- `TimeInForce (59)` must be `GTC (1)` when `MaxFloor (111)` is used.
### \-1161 DEPRECATED\_SCHEMA[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Unable to encode the response in SBE schema 'x'. Please use schema 'y' or higher.
### \-1165 BUY\_OCO\_LIMIT\_MUST\_BE\_BELOW[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A limit order in a buy OCO must be below.
### \-1166 SELL\_OCO\_LIMIT\_MUST\_BE\_ABOVE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A limit order in a sell OCO must be above.
### \-1168 BOTH\_OCO\_ORDERS\_CANNOT\_BE\_LIMIT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- At least one OCO order must be contingent.
### \-1169 INVALID\_TAG\_NUMBER[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid tag number.
### \-1170 TAG\_NOT\_DEFINED\_IN\_MESSAGE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Tag '%s' not defined for this message type.
### \-1171 TAG\_APPEARS\_MORE\_THAN\_ONCE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Tag '%s' appears more than once.
### \-1172 TAG\_OUT\_OF\_ORDER[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Tag '%s' specified out of required order.
### \-1173 GROUP\_FIELDS\_OUT\_OF\_ORDER[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Repeating group '%s' fields out of order.
### \-1174 INVALID\_COMPONENT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Component '%s' is incorrectly populated on '%s' order. Recommendation: '%s'
### \-1175 RESET\_SEQ\_NUM\_SUPPORT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Continuation of sequence numbers to new session is currently unsupported. Sequence numbers must be reset for each new session.
### \-1176 ALREADY\_LOGGED\_IN[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [Logon`<A>`](https://developers.binance.com/docs/binance-spot-api-docs/fix-api) should only be sent once.
### \-1177 GARBLED\_MESSAGE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `CheckSum(10)` contains an incorrect value.
- `BeginString (8)` is not the first tag in a message.
- `MsgType (35)` is not the third tag in a message.
- `BodyLength (9)` does not contain the correct byte count.
- Only printable ASCII characters and SOH (Start of Header) are allowed.
- Tag specified without a value.
- Invalid encodingType.
### \-1178 BAD\_SENDER\_COMPID[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `SenderCompId(49)` contains an incorrect value. The SenderCompID value should not change throughout the lifetime of a session.
### \-1179 BAD\_SEQ\_NUM[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `MsgSeqNum(34)` contains an unexpected value. Expected: '%d'.
### \-1180 EXPECTED\_LOGON[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [Logon`<A>`](https://developers.binance.com/docs/binance-spot-api-docs/fix-api) must be the first message in the session.
### \-1181 TOO\_MANY\_MESSAGES[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Too many messages; current limit is '%d' messages per '%s'.
### \-1182 PARAMS\_BAD\_COMBO[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Conflicting fields: \[%s\]
### \-1183 NOT\_ALLOWED\_IN\_DROP\_COPY\_SESSIONS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Requested operation is not allowed in DropCopy sessions.
### \-1184 DROP\_COPY\_SESSION\_NOT\_ALLOWED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- DropCopy sessions are not supported on this server. Please reconnect to a drop copy server.
### \-1185 DROP\_COPY\_SESSION\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Only DropCopy sessions are supported on this server. Either reconnect to order entry server or send `DropCopyFlag (9406)` field.
### \-1186 NOT\_ALLOWED\_IN\_ORDER\_ENTRY\_SESSIONS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Requested operation is not allowed in order entry sessions.
### \-1187 NOT\_ALLOWED\_IN\_MARKET\_DATA\_SESSIONS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Requested operation is not allowed in market data sessions.
### \-1188 INCORRECT\_NUM\_IN\_GROUP\_COUNT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Incorrect NumInGroup count for repeating group '%s'.
### \-1189 DUPLICATE\_ENTRIES\_IN\_A\_GROUP[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Group '%s' contains duplicate entries.
### \-1190 INVALID\_REQUEST\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- `MDReqID (262)` contains a subscription request id that is already in use on this connection.
- `MDReqID (262)` contains an unsubscription request id that does not match any active subscription.
### \-1191 TOO\_MANY\_SUBSCRIPTIONS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Too many subscriptions. Connection may create up to '%s' subscriptions at a time.
- Similar subscription is already active on this connection. Symbol='%s', active subscription id: '%s'.
### \-1194 INVALID\_TIME\_UNIT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid value for time unit; expected either MICROSECOND or MILLISECOND.
### \-1196 BUY\_OCO\_STOP\_LOSS\_MUST\_BE\_ABOVE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A stop loss order in a buy OCO must be above.
### \-1197 SELL\_OCO\_STOP\_LOSS\_MUST\_BE\_BELOW[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A stop loss order in a sell OCO must be below.
### \-1198 BUY\_OCO\_TAKE\_PROFIT\_MUST\_BE\_BELOW[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A take profit order in a buy OCO must be below.
### \-1199 SELL\_OCO\_TAKE\_PROFIT\_MUST\_BE\_ABOVE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- A take profit order in a sell OCO must be above.
### \-1210 INVALID\_PEG\_PRICE\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid pegPriceType.
### \-1211 INVALID\_PEG\_OFFSET\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid pegOffsetType.
### \-1220 SYMBOL\_DOES\_NOT\_MATCH\_STATUS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- The symbol's status does not match the requested symbolStatus.
### \-1221 INVALID\_SBE\_MESSAGE\_FIELD[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid/missing field(s) in SBE message.
### \-1222 OPO\_WORKING\_MUST\_BE\_BUY[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Working order in an OPO list must be a bid.
### \-1223 OPO\_PENDING\_MUST\_BE\_SELL[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Pending orders in an OPO list must be asks.
### \-1224 WORKING\_PARAM\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Working order must include the '{param}' tag.
### \-1225 PENDING\_PARAM\_NOT\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Pending orders should not include the '%s' tag.
### \-2010 NEW\_ORDER\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- NEW\_ORDER\_REJECTED
### \-2011 CANCEL\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- CANCEL\_REJECTED
### \-2013 NO\_SUCH\_ORDER[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Order does not exist.
### \-2014 BAD\_API\_KEY\_FMT[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- API-key format invalid.
### \-2015 REJECTED\_MBX\_KEY[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Invalid API-key, IP, or permissions for action.
### \-2016 NO\_TRADING\_WINDOW[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- No trading window could be found for the symbol. Try ticker/24hrs instead.
### \-2026 ORDER\_ARCHIVED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Order was canceled or expired with no executed qty over 90 days ago and has been archived.
### \-2035 SUBSCRIPTION\_ACTIVE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- User Data Stream subscription already active.
### \-2036 SUBSCRIPTION\_INACTIVE[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- User Data Stream subscription not active.
### \-2039 CLIENT\_ORDER\_ID\_INVALID[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Client order ID is not correct for this order ID.
### \-2042 MAXIMUM\_SUBSCRIPTION\_IDS[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- Maximum subscription ID reached for this connection.
## Messages for -1010 ERROR\_MSG\_RECEIVED, -2010 NEW\_ORDER\_REJECTED, -2011 CANCEL\_REJECTED, and -2038 ORDER\_AMEND\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
This code is sent when an error has been returned by the matching engine. The following messages which will indicate the specific error:
Error message
Description
"Unknown order sent."
The order (by either `orderId`, `clOrdId`, `origClOrdId`) could not be found.
"Duplicate order sent."
The `clOrdId` is already in use.
"Market is closed."
The symbol is not trading.
"Account has insufficient balance for requested action."
Not enough funds to complete the action.
"Market orders are not supported for this symbol."
`MARKET` is not enabled on the symbol.
"Iceberg orders are not supported for this symbol."
`icebergQty` is not enabled on the symbol.
"Stop loss orders are not supported for this symbol."
`STOP_LOSS` is not enabled on the symbol.
"Stop loss limit orders are not supported for this symbol."
`STOP_LOSS_LIMIT` is not enabled on the symbol.
"Take profit orders are not supported for this symbol."
`TAKE_PROFIT` is not enabled on the symbol.
"Take profit limit orders are not supported for this symbol."
`TAKE_PROFIT_LIMIT` is not enabled on the symbol.
"Order amend is not supported for this symbol."
Order amend keep priority is not enabled on the symbol.
"Price \* QTY is zero or less."
`price` \* `quantity` is too low.
"IcebergQty exceeds QTY."
`icebergQty` must be less than the order quantity.
"This action is disabled on this account."
Contact customer support; some actions have been disabled on the account.
"This account may not place or cancel orders."
Contact customer support; the account has trading ability disabled.
"Unsupported order combination"
The `orderType`, `timeInForce`, `stopPrice`, and/or `icebergQty` combination isn't allowed.
"Order would trigger immediately."
The order's stop price is not valid when compared to the last traded price.
"Cancel order is invalid. Check origClOrdId and orderId."
No `origClOrdId` or `orderId` was sent in.
"Order would immediately match and take."
`LIMIT_MAKER` order type would immediately match and trade, and not be a pure maker order.
"The relationship of the prices for the orders is not correct."
The prices set in the `OCO` is breaking the Price restrictions.
For reference:
`BUY` : `LIMIT_MAKER` `price` < Last Traded Price < `stopPrice`
`SELL` : `LIMIT_MAKER` `price` > Last Traded Price > `stopPrice`
"OCO orders are not supported for this symbol"
`OCO` is not enabled on the symbol.
"Quote order qty market orders are not support for this symbol."
`MARKET` orders using the parameter `quoteOrderQty` are not enabled on the symbol.
"Trailing stop orders are not supported for this symbol."
Orders using `trailingDelta` are not enabled on the symbol.
"Order cancel-replace is not supported for this symbol."
`POST /api/v3/order/cancelReplace` (REST API) or `order.cancelReplace` (WebSocket API) is not enabled on the symbol.
"This symbol is not permitted for this account."
Account and symbol do not have the same permissions. (e.g. `SPOT`, `MARGIN`, etc)
"This symbol is restricted for this account."
Account is unable to trade on that symbol. (e.g. An `ISOLATED_MARGIN` account cannot place `SPOT` orders.)
"Order was not canceled due to cancel restrictions."
Either `cancelRestrictions` was set to `ONLY_NEW` but the order status was not `NEW`
or
`cancelRestrictions` was set to `ONLY_PARTIALLY_FILLED` but the order status was not `PARTIALLY_FILLED`.
"Rest API trading is not enabled." / "WebSocket API trading is not enabled."
Order is being placed or a server that is not configured to allow access to `TRADE` endpoints.
"FIX API trading is not enabled.
Order is placed on a FIX server that is not TRADE enabled.
"Order book liquidity is less than `LOT_SIZE` filter minimum quantity."
Quote quantity market orders cannot be placed when the order book liquidity is less than minimum quantity configured for the `LOT_SIZE` filter.
"Order book liquidity is less than `MARKET_LOT_SIZE` filter minimum quantity."
Quote quantity market orders cannot be placed when the order book liquidity is less than the minimum quantity for `MARKET_LOT_SIZE` filter.
"Order book liquidity is less than symbol minimum quantity."
Quote quantity market orders cannot be placed when there are no orders on the book.
"Order amend (quantity increase) is not supported."
`newQty` must be less than the order quantity.
"The requested action would change no state; rejecting".
The request sent would not have changed the status quo.
(e.g. `newQty` cannot equal the order quantity.)
"Pegged orders are not supported for this symbol."
`pegInstructionsAllowed` has not been enabled.
"This order type may not use pegged price."
You are using parameter `pegPriceType` with an unsupported order type. (e.g. `MARKET`)
"This price peg cannot be used with this order type."
You are using `pegPriceType`\=`MARKET_PEG` for a `LIMIT_MAKER` order.
"Order book liquidity is too low for this pegged order."
The order book doesnt have the best price level to peg the price to.
OPO orders are not supported for this symbol.
Order amend (pending OPO order) is not supported.
You cannot amend the pending quantity of an OPO order
## Errors regarding placing orders via cancelReplace[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
### \-2021 Order cancel-replace partially failed[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This code is sent when either the cancellation of the order failed or the new order placement failed but not both.
### \-2022 Order cancel-replace failed.[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This code is sent when both the cancellation of the order failed and the new order placement failed.
## Filter failures[](https://developers.binance.com/docs/binance-spot-api-docs/errors)
Error message
Description
"Filter failure: PRICE\_FILTER"
`price` is too high, too low, and/or not following the tick size rule for the symbol.
"Filter failure: PERCENT\_PRICE"
`price` is X% too high or X% too low from the average weighted price over the last Y minutes.
"Filter failure: LOT\_SIZE"
`quantity` is too high, too low, and/or not following the step size rule for the symbol.
"Filter failure: MIN\_NOTIONAL"
`price` \* `quantity` is too low to be a valid order for the symbol.
"Filter failure: NOTIONAL"
`price` \* `quantity` is not within range of the `minNotional` and `maxNotional`
"Filter failure: ICEBERG\_PARTS"
`ICEBERG` order would break into too many parts; icebergQty is too small.
"Filter failure: MARKET\_LOT\_SIZE"
`MARKET` order's `quantity` is too high, too low, and/or not following the step size rule for the symbol.
"Filter failure: MAX\_POSITION"
The account's position has reached the maximum defined limit.
This is composed of the sum of the balance of the base asset, and the sum of the quantity of all open `BUY` orders.
"Filter failure: MAX\_NUM\_ORDERS"
Account has too many open orders on the symbol.
"Filter failure: MAX\_NUM\_ALGO\_ORDERS"
Account has too many open stop loss and/or take profit orders on the symbol.
"Filter failure: MAX\_NUM\_ICEBERG\_ORDERS"
Account has too many open iceberg orders on the symbol.
"Filter failure: MAX\_NUM\_ORDER\_AMENDS"
Account has made too many amendments to a single order on the symbol.
"Filter failure: MAX\_NUM\_ORDER\_LISTS"
Account has too many open order lists on the symbol.
"Filter failure: TRAILING\_DELTA"
`trailingDelta` is not within the defined range of the filter for that order type.
"Filter failure: EXCHANGE\_MAX\_NUM\_ORDERS"
Account has too many open orders on the exchange.
"Filter failure: EXCHANGE\_MAX\_NUM\_ALGO\_ORDERS"
Account has too many open stop loss and/or take profit orders on the exchange.
"Filter failure: EXCHANGE\_MAX\_NUM\_ICEBERG\_ORDERS"
Account has too many open iceberg orders on the exchange.
"Filter failure: EXCHANGE\_MAX\_NUM\_ORDER\_LISTS"
Account has too many open order lists on the exchange.
- [10xx - General Server or Network issues](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1000 UNKNOWN](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1001 DISCONNECTED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1002 UNAUTHORIZED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1003 TOO\_MANY\_REQUESTS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1006 UNEXPECTED\_RESP](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1007 TIMEOUT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1008 SERVER\_BUSY](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1013 INVALID\_MESSAGE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1014 UNKNOWN\_ORDER\_COMPOSITION](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1015 TOO\_MANY\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1016 SERVICE\_SHUTTING\_DOWN](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1020 UNSUPPORTED\_OPERATION](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1021 INVALID\_TIMESTAMP](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1022 INVALID\_SIGNATURE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1033 COMP\_ID\_IN\_USE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1034 TOO\_MANY\_CONNECTIONS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1035 LOGGED\_OUT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [11xx - Request issues](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1100 ILLEGAL\_CHARS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1101 TOO\_MANY\_PARAMETERS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1102 MANDATORY\_PARAM\_EMPTY\_OR\_MALFORMED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1103 UNKNOWN\_PARAM](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1104 UNREAD\_PARAMETERS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1105 PARAM\_EMPTY](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1106 PARAM\_NOT\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1108 PARAM\_OVERFLOW](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1111 BAD\_PRECISION](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1112 NO\_DEPTH](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1114 TIF\_NOT\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1115 INVALID\_TIF](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1116 INVALID\_ORDER\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1117 INVALID\_SIDE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1118 EMPTY\_NEW\_CL\_ORD\_ID](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1119 EMPTY\_ORG\_CL\_ORD\_ID](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1120 BAD\_INTERVAL](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1121 BAD\_SYMBOL](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1122 INVALID\_SYMBOLSTATUS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1125 INVALID\_LISTEN\_KEY](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1127 MORE\_THAN\_XX\_HOURS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1128 OPTIONAL\_PARAMS\_BAD\_COMBO](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1130 INVALID\_PARAMETER](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1134 BAD\_STRATEGY\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1135 INVALID\_JSON](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1139 INVALID\_TICKER\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1145 INVALID\_CANCEL\_RESTRICTIONS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1151 DUPLICATE\_SYMBOLS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1152 INVALID\_SBE\_HEADER](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1153 UNSUPPORTED\_SCHEMA\_ID](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1155 SBE\_DISABLED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1158 OCO\_ORDER\_TYPE\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1160 OCO\_ICEBERGQTY\_TIMEINFORCE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1161 DEPRECATED\_SCHEMA](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1165 BUY\_OCO\_LIMIT\_MUST\_BE\_BELOW](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1166 SELL\_OCO\_LIMIT\_MUST\_BE\_ABOVE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1168 BOTH\_OCO\_ORDERS\_CANNOT\_BE\_LIMIT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1169 INVALID\_TAG\_NUMBER](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1170 TAG\_NOT\_DEFINED\_IN\_MESSAGE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1171 TAG\_APPEARS\_MORE\_THAN\_ONCE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1172 TAG\_OUT\_OF\_ORDER](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1173 GROUP\_FIELDS\_OUT\_OF\_ORDER](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1174 INVALID\_COMPONENT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1175 RESET\_SEQ\_NUM\_SUPPORT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1176 ALREADY\_LOGGED\_IN](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1177 GARBLED\_MESSAGE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1178 BAD\_SENDER\_COMPID](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1179 BAD\_SEQ\_NUM](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1180 EXPECTED\_LOGON](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1181 TOO\_MANY\_MESSAGES](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1182 PARAMS\_BAD\_COMBO](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1183 NOT\_ALLOWED\_IN\_DROP\_COPY\_SESSIONS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1184 DROP\_COPY\_SESSION\_NOT\_ALLOWED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1185 DROP\_COPY\_SESSION\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1186 NOT\_ALLOWED\_IN\_ORDER\_ENTRY\_SESSIONS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1187 NOT\_ALLOWED\_IN\_MARKET\_DATA\_SESSIONS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1188 INCORRECT\_NUM\_IN\_GROUP\_COUNT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1189 DUPLICATE\_ENTRIES\_IN\_A\_GROUP](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1190 INVALID\_REQUEST\_ID](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1191 TOO\_MANY\_SUBSCRIPTIONS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1194 INVALID\_TIME\_UNIT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1196 BUY\_OCO\_STOP\_LOSS\_MUST\_BE\_ABOVE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1197 SELL\_OCO\_STOP\_LOSS\_MUST\_BE\_BELOW](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1198 BUY\_OCO\_TAKE\_PROFIT\_MUST\_BE\_BELOW](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1199 SELL\_OCO\_TAKE\_PROFIT\_MUST\_BE\_ABOVE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1210 INVALID\_PEG\_PRICE\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1211 INVALID\_PEG\_OFFSET\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1220 SYMBOL\_DOES\_NOT\_MATCH\_STATUS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1221 INVALID\_SBE\_MESSAGE\_FIELD](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1222 OPO\_WORKING\_MUST\_BE\_BUY](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1223 OPO\_PENDING\_MUST\_BE\_SELL](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1224 WORKING\_PARAM\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-1225 PENDING\_PARAM\_NOT\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2010 NEW\_ORDER\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2011 CANCEL\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2013 NO\_SUCH\_ORDER](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2014 BAD\_API\_KEY\_FMT](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2015 REJECTED\_MBX\_KEY](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2016 NO\_TRADING\_WINDOW](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2026 ORDER\_ARCHIVED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2035 SUBSCRIPTION\_ACTIVE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2036 SUBSCRIPTION\_INACTIVE](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2039 CLIENT\_ORDER\_ID\_INVALID](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2042 MAXIMUM\_SUBSCRIPTION\_IDS](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [Messages for -1010 ERROR\_MSG\_RECEIVED, -2010 NEW\_ORDER\_REJECTED, -2011 CANCEL\_REJECTED, and -2038 ORDER\_AMEND\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [Errors regarding placing orders via cancelReplace](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2021 Order cancel-replace partially failed](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [\-2022 Order cancel-replace failed.](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- [Filter failures](https://developers.binance.com/docs/binance-spot-api-docs/errors)
@@ -1,87 +0,0 @@
---
title: "API Key Types | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types"
fetched_at: "2026-02-26T10:38:07.187Z"
---
# API Key Types
Binance APIs require an API key to access authenticated endpoints for trading, account history, etc.
We support several types of API keys:
- Ed25519 (recommended)
- HMAC
- RSA
This document provides an overview of supported API keys.
**We recommend to use Ed25519 API keys** as it should provide the best performance and security out of all supported key types.
Read [REST API](https://developers.binance.com/docs/binance-spot-api-docs/rest-api.md) or [WebSocket API](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security) documentation to learn how to use different API keys.
### Ed25519[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
Ed25519 keys use asymmetric cryptography. You share your public key with Binance and use the private key to sign API requests. Binance API uses the public key to verify your signature.
Ed25519 keys provide security comparable to 3072-bit RSA keys, but with considerably smaller key, smaller signature size, and faster signature computation.
**We recommend to use Ed25519 API keys.**
Sample Ed25519 key:
```
-----BEGIN PUBLIC KEY-----MCowBQYDK2VwAyEAgmDRTtj2FA+wzJUIlAL9ly1eovjLBu7uXUFR+jFULmg=-----END PUBLIC KEY-----
```
Sample Ed25519 signature:
```
E7luAubOlcRxL10iQszvNCff+xJjwJrfajEHj1hOncmsgaSB4NE+A/BbQhCWwit/usNJ32/LeTwDYPoA7Qz4BA==
```
### HMAC[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
HMAC keys use symmetric cryptography. Binance generates and shares with you a secret key which you use to sign API requests. Binance API uses the same shared secret key to verify your signature.
HMAC signatures are quick to compute and compact.
However, the shared secret must be shared between multiple parties which is less secure than asymmetric cryptography used by Ed25519 or RSA keys.
**HMAC keys are deprecated.** We recommend to migrate to asymmetric API keys, such as Ed25519 or RSA.
Sample HMAC key:
```
Fhs4lGae2qAi6VNjbJjebUAwXrIChb7mlf372UOICMwdKaNdNBGKtfdeUff2TTTT
```
Sample HMAC signature:
```
7f3fc79c57d7a70d2b644ad4589672f4a5d55a62af2a336a0af7d4896f8d48b8
```
### RSA[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
RSA keys use asymmetric cryptography.
You share your public key with Binance and use the private key to sign API requests.
Binance API uses the public key to verify your signature.
We support 2048 and 4096 bit RSA keys.
While RSA keys are more secure than HMAC keys, RSA signatures are much larger than HMAC and Ed25519 which can lead to a degradation to performance.
Sample RSA key (2048 bits):
```
-----BEGIN PUBLIC KEY-----MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyfKiFXpcOhF5rX1XxePNakwN7Etwtn3v05cZNY+ftDHbVZHs/kY6Ruj5lhxVFAq5dv7Ba9/4jPijXuMuIc6Y8nUlqtrrxC8DEOAczw9SKATDYZN9nbLfYlbBFfHzRQUXdAtYCPI6XtxmJBS7aOBb4nZe1SVm+bhLrp0YQnx2P0s+37qkGeVn09m6w9MnWxjgCkkYFPWQkXIu5qOnwx6pNfqDmFD7d7dUc/6PZQ1bKFALu/UETsobmBk82ShbrBhlc0JXuhf9qBR7QASjHjFQ2N+VF2PfH8dm5prZIpz/MFKPkBW4Yuss0OXiD+jQt1J2JUKspLqsIqoXjHQQGjL73wIDAQAB-----END PUBLIC KEY-----
```
Sample RSA signature (2048 bits):
```
wS6q6h77AvH1TqwInoTDdWIIubRCiUP4RLG++GI24twL3BMtX0EEV+YT1eH8Hb8bLe0Rb9OhOHbt1CC3aurzoCTgZvhNek47mg+Bpu8fwQ7eRkXEiWBx5C8BNN73JwnnkZw4UzYvqiwAs162jToV8AL0eN043KJ3MEKCy3C6nyeYOFSg+1Cp637KtAZk3z7aHknSu7/PXSPuwMIpBgFctf8YKGZFAVRbgwlcgUDhXyaGts6OFePGy0jkZKJHawb/w5hoatatsfVmVC4hZ8fsfystQ9k5DNjTm7ROApWaXy9BsfAYcj13O424mqlpkKG4EGnIjOIWB/pRDDQEm2O/xg==
```
- [Ed25519](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
- [HMAC](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
- [RSA](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types)
@@ -1,137 +0,0 @@
---
title: "Commission FAQ | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq"
fetched_at: "2026-02-26T10:38:07.334Z"
---
# Commission Rates
**Disclaimer:**
- The commissions and prices used here are fictional, and do not imply anything about the actual setup on the live exchange.
- This applies only for the SPOT Exchange.
### What are Commission Rates?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
These are the rates that determine the commission to be paid on trades when your order fills for any amount.
### What are the different types of rates?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
There are 3 types:
- `standardCommission` - Standard commission rates on trades from the order.
- `taxCommission` - Tax commission rates on trades from the order.
- `specialCommission` - Extra commission that will be added in specific circumstances.
Standard commission rate may be reduced, depending on promotions for specific trading pairs, applicable discounts, etc.
### How do I know what the commission rates are?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
You can find them using the following requests:
REST API: `GET /api/v3/account/commission`
WebSocket API: `account.commission`
You can also find out the commission rates to a trade from an order using the test order requests with `computeCommissionRates`.
### What is the difference between the response sending a test order with `computeCommissionRates` vs the response from querying commission rates?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
A test order with `computeCommissionRates` returns detailed commission rates for that specific order:
```
{ "standardCommissionForOrder": { "maker": "0.00000050", "taker": "0.00000060" }, "specialCommissionForOrder": { "maker": "0.05000000", "taker": "0.06000000" }, "taxCommissionForOrder": { "maker": "0.00000228", "taker": "0.00000230" }, "discount": { "enabledForAccount": true, "enabledForSymbol": true, "discountAsset": "BNB", "discount": "0.25000000" }}
```
Note: It does not show buyer/seller commissions separately, as these are already taken into account based on the order side.
In contrast, querying commission rates returns your current commission rates for the symbol on your account.
```
{ "symbol": "BTCUSDT", "standardCommission": { "maker": "0.00000040", "taker": "0.00000050", "buyer": "0.00000010", "seller": "0.00000010" }, "specialCommission": { "maker": "0.04000000", "taker": "0.05000000", "buyer": "0.01000000", "seller": "0.01000000" }, "taxCommission": { "maker": "0.00000128", "taker": "0.00000130", "buyer": "0.00000100", "seller": "0.00000100" }, "discount": { "enabledForAccount": true, "enabledForSymbol": true, "discountAsset": "BNB", "discount": "0.25000000" }}
```
### How is the commission calculated?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
Using an example commission configuration:
```
{ "symbol": "BTCUSDT", "standardCommission": { "maker": "0.00000010", "taker": "0.00000020", "buyer": "0.00000030", "seller": "0.00000040" }, "specialCommission": { "maker": "0.01000000", "taker": "0.02000000", "buyer": "0.03000000", "seller": "0.04000000" }, "taxCommission": { "maker": "0.00000112", "taker": "0.00000114", "buyer": "0.00000118", "seller": "0.00000116" }, "discount": { "enabledForAccount": true, "enabledForSymbol": true, "discountAsset": "BNB", "discount": "0.25000000" }}
```
If you placed an order with the following parameters which took immediately and fully filled in a single trade:
Parameter
Value
symbol
BTCUSDT
price
35,000
quantity
0.49975
side
SELL
type
MARKET
Since you sold BTC for USDT, the commission will be paid either in USDT or BNB.
When standard commission is calculated, the received amount is multiplied with the sum of the rates.
Since this order is on the `SELL` side, the received amount is the notional value. (For orders on the `BUY` side, the received amount would be `quantity`.) The order type was `MARKET`, making this the taker order for the trade.
```
Standard Commission = Notional value * (taker + seller) = (35000 * 0.49975) * (0.00000020 + 0.00000040) = 17491.25000000 * 0.00000060 = 0.01049475 USDT
```
Tax commission (if applicable) is calculated similarly:
```
Tax commission = Notional value * (taker + seller) = (35000 * 0.49975) * (0.00000114 + 0.00000116) = 17491.25000000 * 0.00000230 = 0.04022988 USDT
```
Special commission (if applicable) is calculated as:
```
Special commission = Notional value * (taker + seller) = (35000 * 0.49975) * (0.02000000 + 0.04000000) = 17491.25000000 * 0.06000030 = 1049.47500000 USDT
```
If not paying in BNB, the total commission are summed up and deducted from your received amount of `USDT`.
Since `enabledforAccount` and `enabledForSymbol` under `discount` is set to `true`, this means the commission will be paid in BNB assuming you have a sufficient balance.
If paying with BNB, then the standard commission will be reduced based on the `discount`.
First the standard commission and tax commission will be converted into BNB based on the exchange rate. For this example, assume that 1 BNB = 260 USDT.
```
Standard commission (Discounted and in BNB) = (Standard commission * BNB exchange rate) * discount = (0.01049475 * 1/260) * 0.25 = 0.000040364 * 0.25 = 0.000010091
```
Note that the discount **does not apply to tax commissions or special commissions**.
```
Tax Commission (in BNB) = Tax commission * BNB exchange rate = 0.04022988 * (1/260) = 0.00015473Special Commission (in BNB) = Special commission * BNB exchange rate = 1049.47500000 * (1/260) = 4.036442308
```
```
Total Commission (in BNB) = Standard commission (Discounted) + Tax commission (in BNB) + Special commission (in BNB) = 0.000010091 + 0.00015473 + 4.036442308 = 4.036607129
```
If you do not have enough BNB to pay the discounted commission, the full commission will be taken out of your received amount of USDT instead.
- [What are Commission Rates?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
- [What are the different types of rates?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
- [How do I know what the commission rates are?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
- [What is the difference between the response sending a test order with `computeCommissionRates` vs the response from querying commission rates?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
- [How is the commission calculated?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
@@ -1,47 +0,0 @@
---
title: "Market Data Only | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only"
fetched_at: "2026-02-26T10:38:07.444Z"
---
# Market Data Only URLs
These URLs do not require any authentication (i.e. The API key is not necessary) and serve only public market data.
### RESTful API[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only)
On the RESTful API, these are the endpoints you can request on `data-api.binance.vision`:
- [GET /api/v3/aggTrades](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/avgPrice](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/depth](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/exchangeInfo](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
- [GET /api/v3/klines](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/ping](https://developers.binance.com/docs/binance-spot-api-docs/rest-api.md)
- [GET /api/v3/ticker](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/ticker/24hr](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/ticker/bookTicker](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/ticker/price](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/time](https://developers.binance.com/docs/binance-spot-api-docs/rest-api.md)
- [GET /api/v3/trades](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [GET /api/v3/uiKlines](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
Sample request:
```
curl -sX GET "https://data-api.binance.vision/api/v3/exchangeInfo?symbol=BTCUSDT"
```
### Websocket Streams[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only)
Public market data can also be retrieved through the websocket market data using the URL `data-stream.binance.vision`. The streams available through this domain are the same that can be found in the [Websocket Market Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams) documentation.
Note that User Data Streams **cannot** be accessed through this URL.
Sample request:
```
wss://data-stream.binance.vision:443/ws/btcusdt@kline_1m
```
- [RESTful API](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only)
- [Websocket Streams](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only)
-64
View File
@@ -1,64 +0,0 @@
---
title: "OPO | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo"
fetched_at: "2026-02-26T10:38:07.501Z"
---
# One Pays the Other (OPO)
## What is One Pays the Other?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
This is a special behavior of OTO and OTOCO where the received amount from the working order is used for the quantity of the pending order(s). Thus the only balance requirement on order placement is that of the working order.
The received funds from the working order are _locked_ for use by the pending order(s) and not available for trading or withdrawal. If the order list is canceled before the pending order is placed on the Matching Engine then these locked funds are unlocked.
OPO is almost identical to `OTO`, with the exception of the absence of the `quantity` of the pending order(s).
## How can I use this?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
Please refer to the following table:
API
Request
REST API
`POST /api/v3/orderList/opo`
`POST /api/v3/orderList/opoco`
WebSocket API
`orderList.place.opo`
`orderList.place.opoco`
FIX API
NewOrderList `<E>` where OPO `(25046)`\=`true`
## What is the difference with this order list from other order lists?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
- The pending order(s) are placed into the Matching Engine without quantity; the quantity will be based on the received quantity from the working order once it fully fills.
- The received quantity will have commission deducted as appropriate. The commission is taken from the available funds instead (i.e. `free` balances) if the received asset is not BNB and there are enough available funds.
- The quantity of the pending order(s) are evaluated (e.g. filters) after the working order fully fills.
- If a symbol has `LOT_SIZE` and/or `MARKET_LOT_SIZE` filters configured, the quantity of the pending order(s) are adjusted to meet them. Any of the locked quantity not used in the pending order(s) will be unlocked and returned to the `free` balances.
- A pending OPO order's quantity may not be amended until the working order has been fully filled.
- Only working orders on the `BUY` side and pending order(s) on the `SELL` side are accepted.
## Which symbols allow OPO orders?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
Order
Reqired in Exchange Information
OPO
`otoAllowed` and `opoAllowed`
OPOCO
`otoAllowed`, `opoAllowed`, and `ocoAllowed`
- [What is One Pays the Other?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
- [How can I use this?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
- [What is the difference with this order list from other order lists?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
- [Which symbols allow OPO orders?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/opo)
@@ -1,286 +0,0 @@
---
title: "Order Amend Keep Priority | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority"
fetched_at: "2026-02-26T10:38:07.700Z"
---
# Order Amend Keep Priority
**Disclaimer**:
- The symbols and values used here are fictional and do not imply anything about the actual setup on the live exchange.
- For simplicity, the examples in this document do not include commission.
## What is Order Amend Keep Priority?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Order Amend Keep Priority request is used to modify (amend) an existing order **without losing order book priority**.
The following order modifications are allowed:
- reduce the quantity of the order
## How can I amend the quantity of my order?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Use the following requests:
API
Request
REST API
`PUT /api/v3/order/amend/keepPriority`
WebSocket API
`order.amend.keepPriority`
FIX API
OrderAmendKeepPriorityRequest `<XAK>`
## What is the difference between "Cancel an Existing Order and Send a New Order" (cancel-replace) and "Order Amend Keep Priority"?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
**Cancel an Existing Order and Send a New Order** request cancels the old order and places a new order.
Time priority is lost. The new order executes after existing orders at the same price.
**Order Amend Keep Priority** request modifies an existing order in-place.
The amended order keeps its time priority among existing orders at the same price.
For example, consider the following order book:
User
Order ID
Side
Order price
quantity
User A
10
BUY
87,000
1.00
⭐️ YOU
15
BUY
87,000
5.50
User B
20
BUY
87,000
4.00
User C
21
BUY
86,999
2.00
Your order 15 is the second one in the queue based on price and time.
You want to reduce the quantity from 5.50 down to 5.00.
If you use **cancel-replace** to cancel `orderId=15` and place a new order with `qty=5.00`, the order book will look like this:
User
Order ID
Side
Order price
quantity
User A
10
BUY
87,000
1.00
⭐️ YOU
11
BUY
87,000
5.50
User B
20
BUY
87,000
4.00
⭐️ YOU
(new) 22
BUY
87,000
5.00
User C
21
BUY
86,999
2.00
Note that the new order gets a new order ID and you lose time priority: order 22 will trade after the order 20.
If instead you use **Order Amend Keep Priority** to reduce the quantity of `orderId=15` down to `qty=5.00`, the order book will look like this:
User
Order ID
Side
Order price
quantity
User A
10
BUY
87,000
1.00
⭐️ YOU
15
BUY
87,000
(amended) **5.00**
User B
20
BUY
87,000
4.00
User C
21
BUY
86,999
2.00
Note that the order ID stays the same and the order keeps its priority in the queue. Only the quantity of the order changes.
## Does Order Amend Keep Priority affect unfilled order count (rate limits)?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Currently, Order Amend Keep Priority requests charge 0 for unfilled order count.
## How do I know if my order has been amended?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
If the order was amended successfully, the API response contains your order with the updated quantity.
On User Data Stream, you will receive an `"executionReport"` event with execution type `"x": "REPLACED"`.
If the amended order belongs to an order list and the client order ID has changed, you will also receive a "listStatus" event with list status type `"l": "UPDATED"`.
You can also use the following requests to query order modification history:
API
Request
REST API
`GET /api/v3/order/amendments`
WebSocket API
`order.amendments`
## What happens if my amend request does not succeed?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
If the request fails for any reason (e.g. fails the filters, permissions, account restrictions, etc), then the order amend request is rejected and the order remains unchanged.
## Is it possible to reuse the current clientOrderId for my amended order?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Yes.
By default, amended orders get a random new client order ID, but you can pass the current client order ID in the `newClientOrderId` parameter if you wish to keep it.
## Can Iceberg Orders be amended?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Yes.
Note that an iceberg order's visible quantity will only change if `newQty` is below the pre-amended visible quantity.
## Can Order lists be amended?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Orders in an order list can be amended.
Note that OCO order pairs must have the same quantity, since only one of the orders can ever be executed. This means that amending either order affects both orders.
For OTO orders, the working and pending orders can be amended individually.
## Which symbols allow Order Amend Keep Priority?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
This information is available in Exchange Information. Symbols that allow Order Amend Keep Priority requests have `amendAllowed` set to `true`.
- [What is Order Amend Keep Priority?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [How can I amend the quantity of my order?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [What is the difference between "Cancel an Existing Order and Send a New Order" (cancel-replace) and "Order Amend Keep Priority"?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [Does Order Amend Keep Priority affect unfilled order count (rate limits)?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [How do I know if my order has been amended?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [What happens if my amend request does not succeed?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [Is it possible to reuse the current clientOrderId for my amended order?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [Can Iceberg Orders be amended?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [Can Order lists be amended?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
- [Which symbols allow Order Amend Keep Priority?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
@@ -1,391 +0,0 @@
---
title: "Order Count Decrement | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement"
fetched_at: "2026-02-26T10:38:07.751Z"
---
# Spot Unfilled Order Count Rules
To ensure a fair and orderly Spot market, we limit the rate at which new orders may be placed.
The rate limit applies to the number of new, _unfilled_ orders placed within a time interval. That is, orders which are partially or fully filled do not count against the rate limit.
> \[!NOTE\] Unfilled order rate limit rewards efficient traders.
>
> **So long as your orders trade, you can keep trading.**
>
> More information: [How do filled orders affect the rate limit?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
### What are the current rate limits?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
You can query current rate limits using the "exchange information" request.
The `"rateLimitType": "ORDERS"` indicates the current unfilled order rate limit.
Please refer to the API documentation:
API
Request
FIX API
[LimitQuery`<XLQ>`](https://developers.binance.com/docs/binance-spot-api-docs/fix-api)
REST API
[`GET /api/v3/exchangeInfo`](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
WebSocket API
[`exchangeInfo`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
> \[!IMPORTANT\] Order placement requests are also affected by the general request rate limits on REST and WebSocket API and the message limits on FIX API.
>
> If you send too many requests at a high rate, you will be blocked by the API.
### How does the unfilled `ORDERS` rate limit work?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
Every successful request to place an order adds to the unfilled order count for the current time interval. If too many unfilled orders accumulate during the interval, subsequent requests will be rejected.
For example, if the unfilled order rate limit is 100 per 10 seconds:
```
{ "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 100}
```
then you can place at most 100 new orders between 12:34:00 and 12:34:10, then 100 more from 12:34:10 to 12:34:20, and so on.
> \[!TIP\] If the newly placed orders receive fills, your unfilled order count decreases and you may place more orders during the time interval.
>
> More information: [How do filled orders affect the rate limit?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
When an order is rejected by the system due to the unfilled order rate limit, the HTTP status code is set to `429 Too Many Requests` and the error code is `-1015 "Too many new orders"`.
If you encounter these errors, please stop sending orders until the affected rate limit interval expires.
Please refer to the API documentation:
API
Documentation
FIX API
[Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/fix-api)
REST API
[Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits)
WebSocket API
[Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
### Is the unfilled order count tracked by IP address?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
Unfilled order count is tracked **by (sub)account**.
Unfilled order count is shared across all IP addresses, all API keys, and all APIs.
### How do filled orders affect the unfilled order count?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
When an order is filled for the first time (partially or fully), your unfilled order count is decremented by one order for all intervals of the `ORDERS` rate limit. Effectively, orders that trade do not count towards the rate limit, allowing efficient traders to keep placing new orders.
Certain orders provide additional incentive:
- **Orders that do not fill immediately (that is, first fill in the maker phase).**
- Orders that fill large quantities.
In these cases the unfilled order count may be decremented by more than one order for each order that starts trading.
**Notes:**
- **The examples only give a general idea of the behavior.** The 10-second interval is used for simplicity. The actual configuration on the live exchange may be different.
- There is a short delay between the order being filled and the unfilled order count update. Please be careful when your unfilled order count is close to the limit.
- Please refer to [How does unfilled `ORDERS` rate limit work?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement) to see how you can monitor the unfilled order count depending on the API.
**Example 1** — taker:
Time
Action
Unfilled order count
00:00:00
0
00:00:01
Place LIMIT order A
1 — new order (+1)
00:00:02
Place LIMIT order B
2 — new order (+1)
(order B partially filled)
1 — first fill as taker (1)
00:00:03
Place LIMIT order C
2 — new order (+1)
00:00:04
(order B partially filled)
2
00:00:04
(order B filled)
2
00:00:05
Place MARKET order D
3 — new order (+1)
(order D fully filled)
2 — first fill as taker (1)
Note how for every taker order that immediately trades, the unfilled order count is decremented later, allowing you to keep placing orders.
**Example 2** — maker:
Time
Action
Unfilled order count
00:00:00
0
00:00:01
Place LIMIT order A
1 — new order (+1)
00:00:01
Place LIMIT order B
2 — new order (+1)
00:00:02
Place LIMIT order C
3 — new order (+1)
00:00:02
Place LIMIT order D
4 — new order (+1)
00:00:02
Place LIMIT order E
5 — new order (+1)
00:00:03
(order A partially filled)
0 — first fill as maker (5)
00:00:04
Place LIMIT order F
1 — new order (+1)
00:00:04
Place LIMIT order G
2 — new order (+1)
00:00:05
(order A partially filled)
2
00:00:05
(order A filled)
2
00:00:05
(order B partially filled)
0 — first fill as maker (5)
00:00:06
Place LIMIT order H
1 — new order (+1)
Note how for every maker order that is filled later, the unfilled order count is decremented by a higher amount, allowing you to place more orders.
### How do canceled or expired orders affect the unfilled order count?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
Canceling an order does not change the unfilled order count.
Expired orders also do not change the unfilled order count.
**Example:**
Time
Action
Unfilled order count
00:00:00
0
00:00:01
Place LIMIT order A
1 — new order (+1)
00:00:02
Cancel order A
1
00:00:02
Place LIMIT order B
2 — new order (+1)
00:00:03
Place LIMIT FOK order C
3 — new order (+1)
(order C is fully filled)
2 — fill (1)
00:00:05
Place LIMIT order D
3 — new order (+1)
00:00:06
Place LIMIT FOK order E
4 — new order (+1)
(order E expires with no fill)
4
00:00:07
Cancel order D
4
00:00:07
Place LIMIT order F
5 — new order (+1)
### Which time zone does `"interval":"DAY"` use?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
UTC
### What happens if I placed an order yesterday but it is filled the next day?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
New order fills decrease your _current_ unfilled order count regardless of when the orders were placed.
**Example:**
Time
Action
Unfilled order count
2024-01-01 09:00
Place 5 orders: 1..5
5
2024-01-02 00:00
(rate limit interval reset)
0
2024-01-02 09:00
Place 10 orders: 6..15
10
2024-01-02 12:00
(orders 1..5 are filled)
5
2024-01-02 13:00
(orders 6..10 are filled)
0
2024-01-02 14:00
Place 2 orders: 16, 17
2
2024-01-02 15:00
(orders 11..15 are filled)
0
**Note:** You do not get credit for order fills. That is, once the unfilled order count is down to zero, additional fills will not decrease it further. New orders will increase the count as usual.
- [What are the current rate limits?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
- [How does the unfilled `ORDERS` rate limit work?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
- [Is the unfilled order count tracked by IP address?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
- [How do filled orders affect the unfilled order count?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
- [How do canceled or expired orders affect the unfilled order count?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
- [Which time zone does `"interval":"DAY"` use?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
- [What happens if I placed an order yesterday but it is filled the next day?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement)
@@ -1,150 +0,0 @@
---
title: "Pegged Orders | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders"
fetched_at: "2026-02-26T10:38:07.900Z"
---
# Pegged orders
**Disclaimer**:
- This explanation only applies to the SPOT Exchange.
- The symbols and values used here are fictional and do not imply anything about the actual setup on the live exchange.
- For simplicity, the examples in this document do not include commission.
## What are pegged orders?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Pegged orders are essentially **limit orders** with the price derived from the order book.
For example, instead of using a specific price (e.g. SELL 1 BTC for at least 100,000 USDC) you can send orders like “SELL 1 BTC at the best asking price” to queue your order after the orders on the book at the highest price, or “BUY 1 BTC for 100,000 USDT or best offer, IOC” to cherry-pick the sellers at the lowest price, and only that price.
Pegged orders offer a way for market makers to match the best price with minimal latency, while retail users can get quick fills at the best price with minimal slippage.
Pegged orders are also known as “best bid-offer” or BBO orders.
## How can I send a pegged order?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Please refer to the following table:
API
Request
Parameters
REST API
`POST /api/v3/order`
`pegPriceType`:
- `PRIMARY` — best price on the same side of the order book
- `MARKET` — best price on the opposite side of the order book
`pegOffsetType` and `pegOffsetValue PRICE_LEVEL` — offset by existing price levels, deeper into the order book
For order lists: (Please see the API documentation for more details.)
- OCO are using `above*` and `below*` prefixes.
- OTO are using `working*` and `pending*` prefixes.
- OTOCO are using `working*`, `pendingAbove*`, and `pendingBelow*` prefixes.
`POST /api/v3/orderList/*`
`POST /api/v3/cancelReplace`
WebSocket API
`order.place`
`orderList.place.*`
`order.cancelReplace`
FIX API
NewOrderSingle `<D>`
`OrdType=PEGGED`, `<PegInstructions>` component block, `PeggedPrice` field.
NewOrderList `<E>`
OrderCancelRequestAndNewOrderSingle `<XCN>`
Currently, [Smart Order Routing (SOR)](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq) does not support pegged orders.
This sample REST API response shows that for pegged orders, `peggedPrice` reflects the selected price, while `price` is the original order price (zero if not set).
```
{ "symbol": "BTCUSDT", "orderId": 18, "orderListId": -1, "clientOrderId": "q1fKs4Y7wgE61WSFMYRFKo", "transactTime": 1750313780050, "price": "0.00000000", "pegPriceType": "PRIMARY_PEG", "peggedPrice": "0.04000000", "origQty": "1.00000000", "executedQty": "0.00000000", "origQuoteOrderQty": "0.00000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1750313780050, "fills": [], "selfTradePreventionMode": "NONE"}
```
## What order types support pegged orders?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
All order types, with the exception of `MARKET` orders, are supported by this feature.
Since both `STOP_LOSS` and `TAKE_PROFIT` orders place a `MARKET` order once the stop condition is met, these order types cannot be pegged.
### Limit orders[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Pegged limit orders immediately enter the market at the current best price:
- `LIMIT`
- With `pegPriceType=PRIMARY_PEG` only `timeInForce=GTC` is allowed.
- `LIMIT_MAKER`
- Only `pegPriceType=PRIMARY_PEG` is allowed.
### Stop-limit orders[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Pegged stop-limit orders enter the market at the best price when price movement triggers the stop order (via stop price or trailing stop):
- `STOP_LOSS_LIMIT`
- `TAKE_PROFIT_LIMIT`
That is, stop orders use the best price at the time when they are triggered, which is different from the price when the stop order is placed. Only the limit price can be pegged, not the stop price.
### OCO[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
OCO order lists may use peg instructions.
- Any order in OCO can be pegged: both above and below orders, or only one of them.
- Pegged orders enter at the best price when they are placed on the book:
- `LIMIT_MAKER` order enters immediately at the current best price
- `STOP_LOSS_LIMIT` and `TAKE_PROFIT_LIMIT` enter at the best price when they are triggered
- `STOP_LOSS` and `TAKE_PROFIT` orders cannot be pegged.
### OTO and OTOCO[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
OTO order lists may use peg instructions as well.
- Any order in OTO can be pegged: both working and pending orders, or only one of them.
- Pegged working order enters immediately at the current best price.
- Pegged pending limit order enters at the best price after the working order has been filled.
- Pegged pending stop-limit order enters at the best price when it is triggered.
OTOCO order lists may contain pegged orders as well, similar to OTO and OCO.
## Which symbols allow pegged orders?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Please refer to Exchange Information requests and look for the field `pegInstructionsAllowed`. If set to true, pegged orders can be used with the symbol.
## Which Filters are applicable to pegged orders?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
Pegged orders are required to pass all applicable filters with the selected price:
- `PRICE_FILTER`
- `PERCENT_PRICE` and `PERCENT_PRICE_BY_SIDE`
- `NOTIONAL` and `MIN_NOTIONAL` (considering the `quantity`)
If a pegged order specifies `price`, it must pass validation at both `price` and `peggedPrice`.
Contingent pegged orders as well as pegged pending orders of OTO order lists are (re)validated at the trigger time and may be rejected later.
- [What are pegged orders?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [How can I send a pegged order?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [What order types support pegged orders?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [Limit orders](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [Stop-limit orders](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [OCO](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [OTO and OTOCO](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [Which symbols allow pegged orders?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
- [Which Filters are applicable to pegged orders?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/pegged_orders)
-158
View File
@@ -1,158 +0,0 @@
---
title: "SBE FAQ | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq"
fetched_at: "2026-02-26T10:38:07.910Z"
---
# Simple Binary Encoding (SBE) FAQ
The goal of this document is to explain:
- How to receive SBE responses in the SPOT API.
- How to decode SBE responses.
SBE is a serialization format used for low-latency.
This implementation is based on the FIX SBE specification.
- [GitHub repository](https://github.com/FIXTradingCommunity/fix-simple-binary-encoding)
- [HTML document](https://www.fixtrading.org/standards/sbe-online)
### How to get an SBE response[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
#### REST API[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- The `Accept` header must include `application/sbe`.
- Provide the schema ID and version in the `X-MBX-SBE` header as `<ID>:<VERSION>`.
Sample request (REST):
```
curl -sX GET -H "Accept: application/sbe" -H "X-MBX-SBE: 1:0" 'https://api.binance.com/api/v3/exchangeInfo?symbol=BTCUSDT'
```
**Notes:**
- If you provide only `application/sbe` in the Accept header:
- If SBE is not enabled in the exchange, you will receive an HTTP **406 Not Acceptable**.
- If the `<ID>:<VERSION>` provided in the `X-MBX-SBE` header is malformed or invalid, the response will be an SBE-encoded error.
- If the `X-MBX-SBE` header is missing, the response will be an SBE-encoded error.
- If you provide both `application/sbe` and `application/json` in the Accept header:
- If SBE is not enabled in the exchange, the response will fall back to JSON.
- If the `<ID>:<VERSION>` provided in the `X-MBX-SBE` header is malformed or invalid, the response will fall back to JSON.
- If the `X-MBX-SBE` header is missing, the response will fall back to JSON.
#### WebSocket API[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- In the connection URL, add `responseFormat=sbe`.
- Provide the schema ID and version in the parameters `sbeSchemaId=<SCHEMA_ID>` and `sbeSchemaVersion=<SCHEMA_VERSION>` respectively.
Sample request (WebSocket):
```
id=$(date +%s%3N)method="exchangeInfo"params='{"symbol":"BTCUSDT"}'request=$( jq -n \ --arg id "$id" \ --arg method "$method" \ --argjson params "$params" \ '{id: $id, method: $method, params: $params}' )response=$(echo $request | websocat -n1 'wss://ws-api.binance.com:443/ws-api/v3?responseFormat=sbe&sbeSchemaId=1&sbeSchemaVersion=0')
```
**Notes:**
- If you provide only `responseFormat=sbe` in the connection URL:
- If SBE is not enabled in the exchange, the response will be HTTP 400.
- If the `sbeSchemaId=<SCHEMA_ID>` or `sbeSchemaVersion=<SCHEMA_VERSION>` are malformed or invalid, the response will be HTTP 400.
- If you provide both `responseFormat=sbe` and `responseFormat=json`, the response will be HTTP 400.
- All error responses during the HTTP handshake are encoded as JSON with the `Content-Type` header set to `application/json;charset=UTF-8`.
- Once a WebSocket session has been successfully established with SBE enabled, all method responses within that session are encoded in SBE, even in the event SBE becomes disabled.
- This means that if SBE is disabled while your WebSocket connection is active, you will receive an SBE-encoded "SBE is not enabled" error in response to any subsequent request.
- As of writing, we do not recommend using `websocat` to send any request as we have observed issues in how it decodes binary frames. The sample above is only used for reference to show the URL to get an SBE response.
#### FIX API[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
See FIX API's [SBE section](https://developers.binance.com/docs/binance-spot-api-docs/fix-api) for detailed information.
Please continue reading below also.
### Supported APIs[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
REST API, WebSocket API and FIX API for SPOT support SBE.
### SBE Schema[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- The schema to use both for the live exchange and SPOT Testnet will be saved in this repository [here](https://github.com/binance/binance-spot-api-docs/tree/master/sbe/schemas).
- Any updates to the schema will be noted in the [CHANGELOG](https://developers.binance.com/docs/binance-spot-api-docs/CHANGELOG).
### Regarding Legacy support[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- SBE schemas are versioned via two XML attributes, `id` and `version`.
- `id` is incremented when a breaking change is introduced. When this occurs, `version` is reset to 0.
- `version` is incremented when a non-breaking change is introduced. When this occurs, `id` is not modified.
- When a new schema is live the old schema becomes deprecated. **Deprecation occurs even when the new schema only introduces non-breaking changes.**
- A deprecated schema will be supported **for at least 6 months after deprecation**.
For example given this hypothetical timeline:
- January 3024: Schema id 1 version 0 is released. This is the first version so this is usable once SBE is enabled in the exchange.
- March 3024: Schema id 1 version 1 is released. This schema introduces a non-breaking change.
- Schema id 1 version 0 is deprecated, but can still be used for at least another 6 months.
- August 3024: Schema id 2 version 0 is released. This schema introduces a breaking change.
- Schema id 1 version 0 is deprecated, but can still be used for at least another 1 month.
- Schema id 1 version 1 is deprecated, but can still be used for at least another 6 months.
- September 3024: 6 months have passed since the release of Schema id 1 version 1.
- Schema id 1 version 0 is retired.
- February 3025: Schema id 2 version 1 is released. This schema introduces a non-breaking change.
- Schema id 1 version 1 is retired.
- Schema id 2 version 0 is deprecated, but can still be used for at least another 6 months.
- For REST API requests specifying a deprecated `<ID>:<VERSION>` in their `X-MBX-SBE` header:
- the HTTP responses will contain a `X-MBX-SBE-DEPRECATED` header
- the SBE responses will be encoded in the highest compatible schema
- For example, as of 2025-08-27, requests for `X-MBX-SBE: 3:0` will receive responses encoded in schema `3:1`. An SBE decoder for schema `3:0` is expected to decode schema `3:1` gracefully as detailed in the [FIX SBE Specification](https://www.fixtrading.org/standards/sbe-online).
- For WebSocket API connections specifying a deprecated `sbeSchemaId` and `sbeSchemaVersion` in their connection URL:
- the field `sbeSchemaIdVersionDeprecated` will be set to `true` in all `WebSocketResponse` SBE messages
- all SBE responses will be encoded in the highest compatible schema
- For example, as of 2025-08-27, requests for `sbeSchemaId=3&sbeSchemaVersion=0` will receive responses encoded in schema `3:1`. An SBE decoder for schema `3:0` is expected to decode schema `3:1` gracefully as detailed in the [FIX SBE Specification](https://www.fixtrading.org/standards/sbe-online).
- For FIX API, when an SBE request message header specifies a deprecated `schemaId` and `version`:
- the field `sbeSchemaIdVersionDeprecated` will be set to `true` in the `LogonAck` message
- all SBE response messages will be encoded using the highest schema version for the provided `schemaId`
- Requests specifying a retired schemaId/version will fail with HTTP 400 (REST & WebSocket) or reject message (FIX API) .
- In SBE Schema [3:0](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/spot_3_0.xml), a `validValue` named `NonRepresentable` was added to each `enum`. Receipt of this value indicates that additional data is available when using the latest schema.
- In SBE Schema [3:1](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/spot_3_1.xml), a message named `NonRepresentableMessage` was added. Receipt of this message indicates that additional data is available when using the latest schema. This message may be received as a top-level message or embedded in a `data` field when the `data` field's `type` is `messageData`, `messageData8`, `messageData16`, `optionalMessageData`, or `optionalMessageData16`.
- JSON file regarding the schema life-cycle with the dates of the latest, deprecated, and retired schemas for both the live exchange and SPOT Testnet will be saved in this repository [here](https://github.com/binance/binance-spot-api-docs/tree/master/sbe/schemas).
Below is an example JSON based on the hypothetical timeline above:
```
{ "environment": "PROD", "latestSchema": { "id": 2, "version": 1, "releaseDate": "3025-02-01" }, "deprecatedSchemas": [ { "id": 2, "version": 0, "releaseDate": "3024-08-01", "deprecatedDate": "3025-02-01" } ], "retiredSchemas": [ { "id": 1, "version": 1, "releaseDate": "3024-03-01", "deprecatedDate": "3024-08-01", "retiredDate": "3025-02-01" }, { "id": 1, "version": 0, "releaseDate": "3024-01-01", "deprecatedDate": "3024-03-01", "retiredDate": "3024-09-01" } ]}
```
### Generate SBE decoders:[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
1. Download the schema:
- REST/WebSocket API:
- [`spot_prod_latest.xml`](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/spot_prod_latest.xml) for the live exchange.
- [`spot_testnet_latest.xml`](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/spot_testnet_latest.xml) for [SPOT Testnet](https://testnet.binance.vision/).
- FIX API:
- [`spot_fix_prod_latest.xml`](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/spot_fix_prod_latest.xml) for the live exchange.
- [`spot_fix_testnet_latest.xml`](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/spot_fix_testnet_latest.xml) for [SPOT Testnet](https://testnet.binance.vision/).
2. Clone and build [`simple-binary-encoding`](https://github.com/real-logic/simple-binary-encoding):
```
$ git clone https://github.com/real-logic/simple-binary-encoding.git $ cd simple-binary-encoding $ ./gradlew
```
3. Run the SbeTool code generator. (Here are samples for [Java](https://github.com/binance/binance-sbe-java-sample-app), [C++](https://github.com/binance/binance-sbe-cpp-sample-app) and [Rust](https://github.com/binance/binance-sbe-rust-sample-app) decoding the payload from Exchange Information.)
#### Decimal field encoding[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
Unlike the FIX SBE specification, decimal fields have their mantissa and exponent fields encoded separately as primitive fields in order to minimize payload size and the number of encoded fields within messages.
#### Timestamp field encoding[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
Timestamps in SBE responses are in microseconds. This differs from JSON responses, which contain millisecond timestamps by default.
#### Custom field attributes in the schema file[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
A few field attributes prefixed with `mbx:` were added to the schema file for documentation purposes:
- `mbx:exponent`: Points to the exponent field corresponding to the mantissa field
- `mbx:jsonPath`: Contains the name of the equivalent field in the JSON response
- `mbx:jsonValue`: Contains the name of the equivalent ENUM value in the JSON response
- [How to get an SBE response](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- [Supported APIs](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- [SBE Schema](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- [Regarding Legacy support](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
- [Generate SBE decoders:](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq)
-165
View File
@@ -1,165 +0,0 @@
---
title: "SOR FAQ | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq"
fetched_at: "2026-02-26T10:38:08.116Z"
---
# Smart Order Routing (SOR)
**Disclaimer:**
- The symbols and values used here are fictional, and do not imply anything about the actual setup on the live exchange.
- For simplicity, the examples in this document do not include commission.
### What is Smart Order Routing (SOR)?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
**Smart Order Routing (SOR)** allows you to potentially get better liquidity by filling an order with liquidity from other order books with the same base asset and interchangeable quote assets. **Interchangeable quote assets** are quote assets with fixed 1 to 1 exchange rate, such as stablecoins pegged to the same fiat currency.
Note that even though the quote assets are interchangeable, when selling the base asset you will always receive the quote asset of the symbol in your order.
When you place an order using SOR, it goes through the eligible order books, looks for best price levels for each order book in that SOR configuration, and takes from those books if possible.
**Note:** If the order using SOR cannot fully fill based on the eligible order books' liquidity, `LIMIT IOC` or `MARKET` orders will immediately expire, while `LIMIT GTC` orders will place the remaining quantity on the order book you originally submitted the order to.
**Example 1**
Let's consider a SOR configuration containing the symbols `BTCUSDT`, `BTCUSDC` and `BTCUSDP`, and the following `ASK` (`SELL` side) order books for those symbols:
```
BTCUSDT quantity 3 price 30,800BTCUSDT quantity 3 price 30,500BTCUSDC quantity 1 price 30,000BTCUSDC quantity 1 price 28,000BTCUSDP quantity 1 price 35,000BTCUSDP quantity 1 price 29,000
```
If you send a `LIMIT GTC BUY` order for `BTCUSDT` with `quantity=0.5` and `price=31000`, you would match with the best SELL price on the BTCUSDT book at 30,500. You would spend 15,250 USDT and receive 0.5 BTC.
If you send a `LIMIT GTC BUY` order _using SOR_ for `BTCUSDT` with `quantity=0.5` and `price=31000`, you would match with the best SELL price across _all symbols in the SOR_, which is BTCUSDC at price 28,000. You would spend 14,000 USDT (_not_ USDC!) and receive 0.5 BTC.
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "sBI1KM6nNtOfj5tccZSKly", "transactTime": 1689149087774, "price": "31000.00000000", "origQty": "0.50000000", "executedQty": "0.50000000", "cummulativeQuoteQty": "14000.00000000", "status": "FILLED", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1689149087774, "fills": [ { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "28000.00000000", "qty": "0.50000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 0 } ], "workingFloor": "SOR", "selfTradePreventionMode": "NONE", "usedSor": true}
```
**Example 2**
Using the same order book as Example 1:
```
BTCUSDT quantity 3 price 30,800BTCUSDT quantity 3 price 30,500BTCUSDC quantity 1 price 30,000BTCUSDC quantity 1 price 28,000BTCUSDP quantity 1 price 35,000BTCUSDP quantity 1 price 29,000
```
If you send a `LIMIT GTC BUY` order for `BTCUSDT` with `quantity=5` and `price=31000`, you would:
- match with the 3 BTCUSDT at 30,500, and buy 3 BTC for 91,500 USDT
- then match with the 3 BTCUSDT at 30,800, and buy 2 BTC for 61,600 USDT
In total, you spend 153,100 USDT and receive 5 BTC.
If you send the same `LIMIT GTC BUY` order _using SOR_ for `BTCUSDT` with `quantity=5` and `price=31000`, you would:
- match with 1 BTCUSDC at 28,000, and buy 1 BTC for 28,000 USDT
- match with 1 BTCUSDP at 29,000, and buy 1 BTC for 29,000 USDT
- match with 1 BTCUSDC at 30,000, and buy 1 BTC for 30,000 USDT
- match with 3 BTCUSDT at 30,500, and buy 2 BTC for 61,000 USDT
In total, you spend 148,000 USDT and receive 5 BTC.
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "tHonoNjWfOSaKiTygN3bfY", "transactTime": 1689146154686, "price": "31000.00000000", "origQty": "5.00000000", "executedQty": "5.00000000", "cummulativeQuoteQty": "148000.00000000", "status": "FILLED", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1689146154686, "fills": [ { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "28000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 0 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "29000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 1 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "30000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 2 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "30500.00000000", "qty": "2.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 3 } ], "workingFloor": "SOR", "selfTradePreventionMode": "NONE", "usedSor": true}
```
**Example 3**
Using the same order book as Example 1 and 2:
```
BTCUSDT quantity 3 price 30,800BTCUSDT quantity 3 price 30,500BTCUSDC quantity 1 price 30,000BTCUSDC quantity 1 price 28,000BTCUSDP quantity 1 price 35,000BTCUSDP quantity 1 price 29,000
```
If you send a `MARKET BUY` order for `BTCUSDT` _using SOR_ with `quantity=11`, there is only 10 BTC in total available across all eligible order books. Once all the order books in SOR configuration have been exhausted, the remaining quantity of 1 expires.
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "jdFYWTNyzplbNvVJEzQa0o", "transactTime": 1689149513461, "price": "0.00000000", "origQty": "11.00000000", "executedQty": "10.00000000", "cummulativeQuoteQty": "305900.00000000", "status": "EXPIRED", "timeInForce": "GTC", "type": "MARKET", "side": "BUY", "workingTime": 1689149513461, "fills": [ { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "28000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 0 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "29000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 1 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "30000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 2 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "30500.00000000", "qty": "3.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 3 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "30800.00000000", "qty": "3.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 4 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "35000.00000000", "qty": "1.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "tradeId": -1, "allocId": 5 } ], "workingFloor": "SOR", "selfTradePreventionMode": "NONE", "usedSor": true}
```
**Example 4**
Let's consider a SOR configuration containing the symbols `BTCUSDT`, `BTCUSDC` and `BTCUSDP` and the following `BID` (`BUY` side) order book for those symbols:
```
BTCUSDT quantity 5 price 29,500BTCUSDC quantity 5 price 35,000BTCUSDC quantity 5 price 30,000BTCUSDP quantity 5 price 28,000
```
If you send a `LIMIT GTC SELL` order for `BTCUSDT` with `price=29000` and `quantity=10`, you would sell 5 BTC and receive 147,500 USDT. Since there is no better price available on the BTCUSDT book, the remaining (unfilled) quantity of the order will rest there at the price of 29,000.
If you send a `LIMIT GTC SELL` order _using SOR_ for `BTCUSDT`, you would:
- match with 5 BTCUSDC at 35,000 and sell 5 BTC for 175,000 USDT
- match with 5 BTCUSDC at 30,000 and sell 5 BTC for 150,000 USDT
In total, you sell 10 BTC and receive 325,000 USDT.
```
{ "symbol": "BTCUSDT", "orderId": 1, "orderListId": -1, "clientOrderId": "W1iXSng1fS77dvanQJDGA5", "transactTime": 1689147920113, "price": "29000.00000000", "origQty": "10.00000000", "executedQty": "10.00000000", "cummulativeQuoteQty": "325000.00000000", "status": "FILLED", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "workingTime": 1689147920113, "fills": [ { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "35000.00000000", "qty": "5.00000000", "commission": "0.00000000", "commissionAsset": "USDT", "tradeId": -1, "allocId": 0 }, { "matchType": "ONE_PARTY_TRADE_REPORT", "price": "30000.00000000", "qty": "5.00000000", "commission": "0.00000000", "commissionAsset": "USDT", "tradeId": -1, "allocId": 1 } ], "workingFloor": "SOR", "selfTradePreventionMode": "NONE", "usedSor": true}
```
**Summary: The goal of SOR is to potentially access better liquidity across order books with interchangeable quote assets. Better liquidity access can fill orders more fully and at better prices during an order's taker phase.**
### What symbols support SOR?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
You can find the current SOR configuration in Exchange Information (`GET /api/v3/exchangeInfo` for Rest, and `exchangeInfo` on Websocket API).
```
{ "sors": [ { "baseAsset": "BTC", "symbols": ["BTCUSDT", "BTCUSDC", "BTCUSDP"] } ]}
```
The `sors` field is optional. It is omitted in responses if SOR is not available.
### How do I place an order using SOR?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
On the Rest API, the request is `POST /api/v3/sor/order`.
On the WebSocket API, the request is `sor.order.place`.
### In the API response, there's a field called `workingFloor`. What does that field mean?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
This is a term used to determine where the order's last activity occurred (filling, expiring, or being placed as new, etc.).
If the `workingFloor` is `SOR`, this means your order interacted with other eligible order books in the SOR configuration.
If the `workingFloor` is `EXCHANGE`, this means your order interacted on the order book that you sent that order to.
### In the API response, `fills` contain fields `matchType` and `allocId`. What do they mean?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
`matchType` field indicates a non-standard order fill.
When your order is filled by SOR, you will see `matchType: ONE_PARTY_TRADE_REPORT`, indicating that you did not trade directly on the exchange (`tradeId: -1`). Instead your order is filled by _allocations_.
`allocId` field identifies the allocation so that you can query it later.
### What are allocations?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
**An allocation** is a transfer of an asset from the exchange to your account. For example, when SOR takes liquidity from eligible order books, your order is filled by allocations. In this case you don't trade directly, but rather receive allocations from SOR corresponding to the trades made by SOR on your behalf.
```
[ { "symbol": "BTCUSDT", // Symbol the order was submitted to "allocationId": 0, "allocationType": "SOR", "orderId": 2, "orderListId": -1, "price": "30000.00000000", // Price of the fill "qty": "5.00000000", // Quantity of the fill "quoteQty": "150000.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "time": 1688379272280, // Time the allocation occurred "isBuyer": true, "isMaker": false, "isAllocator": false }]
```
### How do I query orders that used SOR?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
You can find them the same way you query any other order. The main difference is that in the response for an order that used SOR there are two extra fields: `usedSor` and `workingFloor`.
### How do I get details of my fills for orders that used SOR?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
When SOR orders trade against order books other than the symbol submitted with the order, the order is filled with an **allocation** and not a trade. Orders placed with SOR can potentially have both allocations and trades.
In the API response, you can review the `fills` fields. Allocations have an `allocId` and `"matchType": "ONE_PARTY_TRADE_REPORT"`, while trades will have a non-negative `tradeId`.
Allocations can be queried using `GET /api/v3/myAllocations` (Rest API) or `myAllocations` (WebSocket API).
Trades can be queried using `GET /api/v3/myTrades` (Rest API) or `myTrades` (WebSocket API).
- [What is Smart Order Routing (SOR)?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [What symbols support SOR?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [How do I place an order using SOR?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [In the API response, there's a field called `workingFloor`. What does that field mean?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [In the API response, `fills` contain fields `matchType` and `allocId`. What do they mean?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [What are allocations?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [How do I query orders that used SOR?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
- [How do I get details of my fills for orders that used SOR?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
@@ -1,608 +0,0 @@
---
title: "Spot Glossary | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary"
fetched_at: "2026-02-26T10:38:08.010Z"
---
# SPOT API Glossary
**Disclaimer:** This glossary refers only to the SPOT API Implementation. The definition for these terms may differ with regards to Futures, Options, and other APIs by Binance.
### A[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`ACK`
- `newOrderRespType` enum. Stands for a type of order response in JSON where only the following fields are emitted: `symbol`, `orderId`, `orderListId`, `clientOrderId`, and `transactTime`.
`aggTrade`/Aggregate trade
- Aggregation of one or more individual trades from the same taker order that got filled at the same time and price.
allocation
- Transfer of asset from the exchange to your account (e.g., when an order is filled by SOR instead of trading directly).
`allocationId`
- Unique identifier of an allocation on a symbol.
`allocationType`
- See [AllocationType](https://developers.binance.com/docs/binance-spot-api-docs/enums)
`askPrice`
- In ticker responses: the lowest price on the `SELL` side.
`askQty`
- In ticker responses: total quantity offered at the lowest price on the `SELL` side.
`asks`
- Orders on the `SELL` side.
`avgPrice`
- Represents the volume-weighted average price for a set interval of minutes.
---
### B[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`baseAsset`
- The first asset in the symbol (e.g. `BTC` is the `base asset` of symbol `BTCUSDT`), which represents the asset being bought and sold (the `quantity`).
`baseAssetPrecision`
- A field found in Exchange Information that shows the number of decimals allowed on the `baseAsset`.
`baseCommissionPrecision`
- A field found in Exchange Information that represents the number of decimals base asset commission will be calculated to.
`bidPrice`
- In ticker responses: the highest price on the `BUY` side.
`bidQty`
- In ticker responses: total quantity offered at the highest price on the `BUY` side.
`bids`
- Orders on the `BUY` side.
`BREAK`
- Symbol's trading status that represents the symbol is not available for trading, which can happen during expected downtime. Market data is not generated during `BREAK`.
`BUY`
- An enum in the `side` parameter when a user wants to purchase an asset (e.g. `BTC`).
---
### C[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`CANCELED`
- Order `status` indicating the order has been canceled by the user.
`cancelReplaceMode`
- Parameter used in Cancel Replace orders that define whether the New Order Placement should proceed if the Cancel Request fails.
`clientOrderId`
- A field, which can be set by the user, in the JSON response for order placement requests to identify the newly placed order.
`commission`
- The fee that was paid on a trade.
`commissionAsset`
- The asset the commission fees were deducted from.
Counter Order Id
- A field in User Data Stream execution reports that indicates the counterparty order in a prevented match.
Counter Symbol
- A field in User Data Stream execution reports that indicates the symbol of the counterparty order in a prevented match.
`cummulativeQuoteQty`
- The accumulation of the `price` \* `qty` for each fill of an order.
---
### D[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
Data Source
- Specifies where the endpoint or request is retrieving their data.
---
### E[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`executedQty`
- The field that shows how much of the quantity was filled in an order.
`EXPIRED`
- Order `status` indicating the order was canceled according to the order type's rules or by the exchange.
`EXPIRED_IN_MATCH`
- Order `status` indicating the order was canceled by the exchange due to STP. (e.g. an order with `EXPIRE_TAKER` will match with existing orders on the book with the same account or same `tradeGroupId`)
---
### F[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`filters`
- Defines the trading rules on the exchange.
`FOK`/ Fill or Kill
- `timeInForce` enum where the order will not fill and expire if the order cannot be fully filled.
`free`
- The amount of an asset in a user's balances that can be used to trade or withdraw.
`FULL`
- `newOrderRespType` enum. Stands for a type of order response in JSON, where all the order information is emitted, including orders `fills` field.
---
### G[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`GTC`/ Good Til Canceled
- `timeInForce` enum where the order will remain active until it is canceled or fully filled.
---
### H[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`HALT`
- Symbol's trading status that represents the symbol is not available for trading, which can happen during emergency downtime. Market data is still generated during `HALT`.
---
### I[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`intervalNum`
- Describes the amount of time in the interval (e.g. if `interval` is `SECOND` and `intervalNum` is 5, then this will be interpreted as every 5 seconds).
`IOC` / Immediate or Canceled
- `timeInForce` enum where the order tries to fill as much as possible, and the remaining unfilled quantity will expire.
`isBestMatch`
- Field in the Response JSON that determines if the price of the trade was the best available on the exchange.
`isBuyerMaker`
- Field in the Response JSON that indicates if the Buy side (the Buyer) was also the market maker (the Maker).
`isWorking`
- Field in the JSON that shows if the order has started working on the order book.
---
### K[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`kline`
- Identifies the open, close, high, low price, trading volume, and other market data, of a symbol at a specified time for a specific duration. Also known as a Candlestick.
---
### L[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
Last Prevented Quantity
- Order quantity that expired due to STP.
`lastPrice`
- Price of the latest trade.
`lastQty`
- Total quantity traded at the `lastPrice`.
`LIMIT`
- a `type` of order where the execution price will be no worse than the order's set price. The execution price is limited to be the set price or better.
`LIMIT_MAKER`
- A `type` of order where the order can only be a maker order (i.e. The order cannot immediately match and take).
`limitClientOrderId`
- A parameter used in placing OCO orders that identifies the `LIMIT_MAKER` pair of the OCO Order.
`listClientOrderId`
- A parameter used in placing OCO Orders that identifies the pair of orders.
`locked`
- The amount of an asset in a user's balances that are currently locked in open orders and other services by the platform.
---
### M[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`MARKET`
- A `type` of order where the user buys or sells an asset at the best available prices and liquidity until the order is fully filled or the order book's liquidity is exhausted.
Matching Engine
- This can either refer to a Data Source in the documentation which means the response is coming from the engine.
- Or this is referred to as the system that handles all the requests and matches orders.
Match Type
- Field in the order response or execution report indicating if the order was filled by the [SOR](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq)
Memory
- Data Source where the response is coming from the API's internal memory or cache.
---
### N[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`NEW`
- Order `status` where a order has been successfully sent to the Matching Engine.
`newClientOrderId`
- Parameter used in the SPOT API to assign the `clientOrderId` for the order being placed or the cancel message.
Notional value
- The `price` \* `qty` value.
---
### O[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`OCO`
- One-Cancels-the-Other type of order that is composed by a pair of orders (e.g. `STOP_LOSS` or `STOP_LOSS_LIMIT` paired with a `LIMIT_MAKER` order) with the condition that if one of the orders execute, the other is automatically expired.
`OPO`
- [One-Pays-The-Other](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/opo.md), a special subset of OTO.
- When the working order fully fills, the accumulated received quantity is used for the quantity of the pending order.
`OPOCO`
- [One-Pays-The-Other](https://github.com/binance/binance-spot-api-docs/blob/master/faqs/opo.md), a special subset of OTOCO.
- When the working order fully fills, the accumulated received quantity is used for the quantity of the pending OCO pair.
Order Amend Keep Priority
- See [Order Amend Keep Priority](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority)
Order Book
- List of the open bids and asks for a symbol.
Order List
- Multiple orders grouped together as a unit. See `OCO` and/or `OTO`
`orderId`
- A field in the order response that uniquely identifies the order on a symbol.
`origQty`
- The original `quantity` that was sent during order placement.
`origClientOrderId`
- Field used when canceling or querying an order by providing the `clientOrderId`.
`OTO`
- One-Triggers-the-Other type of order that has a working order and a pending order.
- When the working order fully fills, the pending order is automatically placed.
`OTOCO`
- One-Triggers-a-One-Cancels-the-Other order has a working order, and an OCO pair for the pending orders.
- When the working order fully fills, the pending OCO pair is automatically placed.
---
### P[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`PARTIALLY_FILLED`
- Order `status` indicating that part of the order has been partially filled.
Pending order
- An order in an order list that is only placed on the order book when the corresponding working order is fully filled.
- A single order list can contain either a single pending order, or 2 pending orders forming an OCO.
- In the single order case, almost any order type is supported, with the exception of `MARKET` orders using `quoteOrderQty`.
`PENDING_NEW`
- Order `status` indicating that the pending orders of an order list have been accepted by the engine, but are not yet placed on the order book.
Prevented execution price
- A field in User Data Stream execution reports showing the price of a prevented self-trade. See [STP](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq).
Prevented execution quantity
- A field in the User Data Stream showing the quantity of a prevented self-trade. See [STP](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq).
Prevented execution quote quantity
- A field in the User data Stream showing the quote quantity of the prevented self-trade. See [STP](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq).
`preventedQuantity`
- Order quantity expired due to STP events.
Prevented Match
- When order(s) expire due to the STP, a "prevented match" records the event.
`preventedMatchId`
- When used in combination with `symbol`, can be used to query a prevented match of the expired order.
---
### Q[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`quantity`
- Parameter used to specify the amount of the `base asset` to buy or sell.
`quoteAsset`
- The second asset in the symbol (e.g. `USDT` is the `quote asset` of symbol `BTCUSDT`) which represents the asset being used to quote prices (the `price`).
`quoteAssetPrecision`
- A field found in Exchange Information that shows the number of decimals allowed on the `quoteAsset`.
`quoteCommissionPrecision`
- A field found in Exchange Information that represents the number of decimals quote asset commission will be calculated to.
`quoteOrderQty`
- `MARKET` order parameter that specifies the amount of the quote asset one wants to spend/receive in a "Reverse MARKET order".
`quoteQty`
- `price` \* `qty`; the notional value.
---
### R[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`recvWindow`
- Parameter in the APIs that can be used to specify the number of milliseconds after the `timestamp` the request is valid for.
`RESULT`
- `newOrderRespType` enum. Stands for a type of order response in JSON, where all the order information is emitted, except order's `fills` field.
Reverse `MARKET` order
- A `MARKET` order that is specified using the `quoteOrderQty` instead of the `quantity`.
---
### S[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
Self Trade Prevention (STP)
- Self Trade Prevention is a feature that prevents orders of users, or the user's `tradeGroupId` from matching against their own. Read [STP FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq) to learn more.
`selfTradePreventionMode`
- A parameter used to specify what the system will do if an order could cause a self-trade.
`SELL`
- An enum in the `side` used when a user wants to sell an asset (e.g. BTC).
Smart Order Routing (SOR)
- Smart Order Routing uses interchangeable quote assets to improve liquidity. Read [SOR FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq) to learn more.
`specialCommissionForOrder`/`specialCommission`
- See [Commission FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
`SPOT`
- This is to distinguish a type of trading, where the purchase and delivery of a asset is made immediately.
`standardCommissionForOrder`/`standardCommission`
- See [Commission FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
`stopClientOrderId`
- A parameter used in placing OCO orders that identifies the `STOP_LOSS` or `STOP_LOSS_LIMIT` pair of the OCO Order.
`stopPrice`
- The price used in algorithmic orders (e.g. `STOP_LOSS`, `TAKE_PROFIT`) that determines when an order will be triggered to be placed on the order book.
- The price used in trailing algorithmic orders (e.g. `STOP_LOSS`, `TAKE_PROFIT`) to determine when trailing price tracking begins.
`STOP_LOSS`
- A `type` of algorithmic order where once the market price hits the `stopPrice`, a `MARKET` order is placed on the order book.
`STOP_LOSS_LIMIT`
- A `type` of algorithmic order where once the market price hits the `stopPrice`, a `LIMIT` order is placed on the order book.
`strategyId`
- Arbitrary numeric value identifying the order within an order strategy.
`strategyType`
- Arbitrary numeric value identifying the order strategy.
`symbol`
- A trading pair, composed of a `base asset` and a `quote asset`. (e.g. BTCUSDT and BNBBTC)
---
### T[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`TAKE_PROFIT`
- A `type` of algorithmic order where once the market price hits the `stopPrice`, a `MARKET` order is placed on the order book.
`TAKE_PROFIT_LIMIT`
- A `type` of algorithmic order where once the market price hits the `stopPrice`, a `LIMIT` order is placed on the order book.
`taxCommissionForOrder`/`taxCommission`
- See [Commission FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/commission_faq)
`ticker`
- Reports the price change, and other maker data, of a symbol within a certain rolling interval.
`time`
- For trade/allocation queries: the time when trades/allocations were executed.
- For order queries: the time when orders were created.
`timeInForce`
- Determines the taker behavior of an order, if an order can be a maker order, and how long the order will stay on the order book before it expires.
- Supported enums are `GTC`, `IOC`, and `FOK`.
`tradeGroupId`
- Group of accounts that belong to the same "trade group".
`TRADING`
- Trading status where orders can be placed.
`trailingDelta`
- Trailing Stop Order parameter that specifies the delta price change required before order activation.
`trailingTime`
- The time when the trailing order is now active and tracking price changes.
`transactTime`
- The time when the order was updated: placed, filled, or canceled. This field (as well as all timestamp related fields) will be in milliseconds by default in JSON responses.
---
### U[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`uiKlines`
- Modified candlestick data that is optimized for presentation of candlestick charts.
`updateTime`
- Last update to the order. This field (as well as all timestamp related fields) will be in milliseconds by default in JSON responses.
User Data Stream
- WebSocket stream used to get real-time information of a user's account. (e.g. Changes to Balances, Order Updates, etc.) Read [User Data Streams](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream) to learn more.
`usedSor`
- Indicates if the order was placed through [SOR](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sor_faq).
---
### W[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`weightedAveragePrice`
- The volume weighted average price in the last x minutes.
`workingFloor`
- A field that determines whether the order is being filled by the SOR or by the order book the order was submitted to.
Working order
- An order in an order list that is immediately placed on the order book, and will trigger the placement of one or multiple pending order(s) when it becomes fully filled.
- An order in an order list that always consists of a single `LIMIT` or `LIMIT_MAKER` order.
`workingTime`
- The time when the order started working on the order book.
---
### X[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
`X-MBX-ORDER-COUNT-XX`
- Response header that is emitted when a user places an order, indicating the current order count for the interval XX for that account.
`X-MBX-USED-WEIGHT-XX`
- Response header that is emitted when a user sends any request to the API, indicating the current used request weight for the XX interval by the user's IP.
- [A](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [B](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [C](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [D](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [E](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [F](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [G](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [H](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [I](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [K](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [L](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [M](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [N](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [O](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [P](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [Q](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [R](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [S](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [T](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [U](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [W](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
- [X](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary)
-369
View File
@@ -1,369 +0,0 @@
---
title: "STP FAQ | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq"
fetched_at: "2026-02-26T10:38:08.165Z"
---
# 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?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
Self Trade Prevention (or STP) prevents orders of users, or the user's `tradeGroupId` to match against their own.
### What defines a self-trade?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
A self-trade can occur in either scenario:
- The order traded against the same account.
- The order traded against an account with the same `tradeGroupId`.
### What happens when STP is triggered?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
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:
Taker Order STP Mode
Maker Order STP Mode
Effective STP Mode
`TRANSFER`
`TRANSFER`
`TRANSFER`
`TRANSFER`
`EXPIRE_MAKER`, `EXPIRE_TAKER`, `EXPIRE_BOTH`, `NONE`, `DECREMENT`
`DECREMENT`
`EXPIRE_MAKER`, `EXPIRE_TAKER`, `EXPIRE_BOTH`, `NONE`, `DECREMENT`
ANY STP MODE
STP mode of the Taker Order
### What is a Trade Group Id?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
Different accounts with the same `tradeGroupId` are considered part of the same "trade group". Orders submitted by members of a trade group are eligible for STP according to the taker-order's STP mode.
A user can confirm if their accounts are under the same `tradeGroupId` from the API either from `GET /api/v3/account` (REST API) or `account.status` (WebSocket API) for each account.
The field is also present in the response for `GET /api/v3/preventedMatches` (REST API) or `myPreventedMatches` (WebSocket API).
If the value is `-1`, then the `tradeGroupId` has not been set for that account, so the STP may only take place between orders of the same account.
### What is a Prevented Match?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
When a self-trade is prevented, a prevented match is created. The orders in the prevented match have their prevented quantities increased and one or more orders expire.
This is not to be confused with a trade, as no orders will match.
This is a record of what orders could have self-traded.
This can be queried through the endpoint `GET /api/v3/preventedMatches` on the REST API or `myPreventedMatches` on the WebSocket API.
This is a sample of the output request for reference:
```
[ { "symbol": "BTCDUSDT", // Symbol of the orders "preventedMatchId": 8, // Identifies the prevented match of the expired order(s) for the symbol. "takerOrderId": 12, // Order Id of the Taker Order "makerOrderId": 10, // Order Id of the Maker Order "tradeGroupId": 1, // Identifies the Trade Group Id. (If the account is not part of a trade group, this will be -1.) "selfTradePreventionMode": "EXPIRE_BOTH", // STP mode that expired the order(s). "price": "50.00000000", // Price at which the match occurred. "takerPreventedQuantity": "1.00000000", // Taker's remaining quantity before the STP. Only appears if the STP mode is EXPIRE_TAKER, EXPIRE_BOTH or DECREMENT. "makerPreventedQuantity": "10.00000000", // Maker's remaining quantity before the STP. Only appears if the STP mode is EXPIRE_MAKER, EXPIRE_BOTH, or DECREMENT. "transactTime": 1663190634060 // Time the order(s) expired due to STP. }]
```
### What is "prevented quantity?"[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
STP events expire quantity from open orders. The STP modes `EXPIRE_TAKER`, `EXPIRE_MAKER`, and `EXPIRE_BOTH` expire all remaining quantity on the affected orders, resulting in the entire open order being expired.
Prevented quantity is the amount of quantity that is expired due to STP events for a particular order. User stream execution reports for orders involved in STP may have these fields:
```
{ "A": "3.000000", // Prevented Quantity "B": "3.000000" // Last Prevented Quantity}
```
`B` is present for execution type `TRADE_PREVENTION`, and is the quantity expired due to that individual STP event.
`A` is the cumulative quantity expired due to STP over the lifetime of the order. For `EXPIRE_TAKER`, `EXPIRE_MAKER`, and `EXPIRE_BOTH` modes this will always be the same value as `B`.
API responses for orders which expired due to STP will also have a `preventedQuantity` field, indicating the cumulative quantity expired due to STP over the lifetime of the order.
While an order is open, the following equation holds true:
```
original order quantity - executed quantity - prevented quantity = quantity available for further execution
```
When an order's available quantity goes to zero, the order will be removed from the order book and the status will be one of `EXPIRED_IN_MATCH`, `FILLED`, or `EXPIRED`.
### How do I know which symbol uses STP?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
Symbols may be configured to allow different sets of STP modes and take different default STP modes.
`defaultSelfTradePreventionMode` - Orders will use this STP mode if the user does not provide one on order placement.
`allowedSelfTradePreventionModes` - Defines the allowed set of STP modes for order placement on that symbol.
For example, if a symbol has the following configuration:
```
{ "defaultSelfTradePreventionMode": "NONE", "allowedSelfTradePreventionModes": ["NONE", "EXPIRE_TAKER", "EXPIRE_BOTH"]}
```
Then that means if a user sends an order with no `selfTradePreventionMode` provided, then the order sent will have the value of `NONE`.
If a user wants to explicitly specify the mode they can pass the enum `NONE`, `EXPIRE_TAKER`, or `EXPIRE_BOTH`.
If a user tries to specify `EXPIRE_MAKER` for orders on this symbol, they will receive an error:
```
{ "code": -1013, "msg": "This symbol does not allow the specified self-trade prevention mode."}
```
### How do I know if an order expired due to STP?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
The order will have the status `EXPIRED_IN_MATCH`.
### STP Examples[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
For all these cases, assume that all orders for these examples are made on the same account.
**Scenario A- A user sends a new order with selfTradePreventionMode:`NONE` that will match with another order of theirs that is already on the book.**
```
Maker Order: symbol=BTCUSDT side=BUY type=LIMIT quantity=1 price=1 selfTradePreventionMode=NONETaker Order: symbol=BTCUSDT side=SELL type=LIMIT quantity=1 price=1 selfTradePreventionMode=NONE
```
**Result**: No STP is triggered and the orders will match.
Order Status of the Maker Order
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "FaDk4LPRxastaICEFE9YTf", "price": "1.000000", "origQty": "1.000000", "executedQty": "1.000000", "cummulativeQuoteQty": "1.000000", "status": "FILLED", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670217090310, "updateTime": 1670217090330, "isWorking": true, "workingTime": 1670217090310, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE"}
```
Order Status of the Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 3, "orderListId": -1, "clientOrderId": "Ay48Vtpghnsvy6w8RPQEde", "transactTime": 1670207731263, "price": "1.000000", "origQty": "1.000000", "executedQty": "1.000000", "cummulativeQuoteQty": "1.000000", "status": "FILLED", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "workingTime": 1670207731263, "fills": [ { "price": "1.000000", "qty": "1.000000", "commission": "0.000000", "commissionAsset": "USDT", "tradeId": 1 } ], "selfTradePreventionMode": "NONE"}
```
**Scenario B- A user sends an order with `EXPIRE_MAKER` that would match with their orders that are already on the book.**
```
Maker Order 1: symbol=BTCUSDT side=BUY type=LIMIT quantity=1.2 price=1.2 selfTradePreventionMode=NONEMaker Order 2: symbol=BTCUSDT side=BUY type=LIMIT quantity=1.3 price=1.1 selfTradePreventionMode=NONEMaker Order 3: symbol=BTCUSDT side=BUY type=LIMIT quantity=8.1 price=1 selfTradePreventionMode=NONETaker Order 1: symbol=BTCUSDT side=SELL type=LIMIT quantity=3 price=1 selfTradePreventionMode=EXPIRE_MAKER
```
**Result**: The orders that were on the book will expire due to STP, and the taker order will go on the book.
Maker Order 1
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "wpNzhSclc16pV8g5THIOR3", "price": "1.200000", "origQty": "1.200000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670217957437, "updateTime": 1670217957498, "isWorking": true, "workingTime": 1670217957437, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE", "preventedMatchId": 0, "preventedQuantity": "1.200000"}
```
Maker Order 2
```
{ "symbol": "BTCUSDT", "orderId": 3, "orderListId": -1, "clientOrderId": "ZT9emqia99V7x8B6FW0pFF", "price": "1.100000", "origQty": "1.300000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670217957458, "updateTime": 1670217957498, "isWorking": true, "workingTime": 1670217957458, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE", "preventedMatchId": 1, "preventedQuantity": "1.300000"}
```
Maker Order 3
```
{ "symbol": "BTCUSDT", "orderId": 4, "orderListId": -1, "clientOrderId": "8QZ3taGcU4gND59TxHAcR0", "price": "1.000000", "origQty": "8.100000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670217957478, "updateTime": 1670217957498, "isWorking": true, "workingTime": 1670217957478, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE", "preventedMatchId": 2, "preventedQuantity": "8.100000"}
```
Output of the Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 5, "orderListId": -1, "clientOrderId": "WRzbhp257NhZsIJW4y2Nri", "transactTime": 1670217957498, "price": "1.000000", "origQty": "3.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "workingTime": 1670217957498, "fills": [], "preventedMatches": [ { "preventedMatchId": 0, "makerOrderId": 2, "price": "1.200000", "makerPreventedQuantity": "1.200000" }, { "preventedMatchId": 1, "makerOrderId": 3, "price": "1.100000", "makerPreventedQuantity": "1.300000" }, { "preventedMatchId": 2, "makerOrderId": 4, "price": "1.000000", "makerPreventedQuantity": "8.100000" } ], "selfTradePreventionMode": "EXPIRE_MAKER"}
```
**Scenario C - A user sends an order with `EXPIRE_TAKER` that would match with their orders already on the book.**
```
Maker Order 1: symbol=BTCUSDT side=BUY type=LIMIT quantity=1.2 price=1.2 selfTradePreventionMode=NONEMaker Order 2: symbol=BTCUSDT side=BUY type=LIMIT quantity=1.3 price=1.1 selfTradePreventionMode=NONEMaker Order 3: symbol=BTCUSDT side=BUY type=LIMIT quantity=8.1 price=1 selfTradePreventionMode=NONETaker Order 1: symbol=BTCUSDT side=SELL type=LIMIT quantity=3 price=1 selfTradePreventionMode=EXPIRE_TAKER
```
**Result**: The orders already on the book will remain, while the taker order will expire.
Maker Order 1
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "NpwW2t0L4AGQnCDeNjHIga", "price": "1.200000", "origQty": "1.200000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670219811986, "updateTime": 1670219811986, "isWorking": true, "workingTime": 1670219811986, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE"}
```
Maker Order 2
```
{ "symbol": "BTCUSDT", "orderId": 3, "orderListId": -1, "clientOrderId": "TSAmJqGWk4YTB2yA9p04UO", "price": "1.100000", "origQty": "1.300000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670219812007, "updateTime": 1670219812007, "isWorking": true, "workingTime": 1670219812007, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE"}
```
Maker Order 3
```
{ "symbol": "BTCUSDT", "orderId": 4, "orderListId": -1, "clientOrderId": "L6FmpCJJP6q4hCNv4MuZDG", "price": "1.000000", "origQty": "8.100000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670219812026, "updateTime": 1670219812026, "isWorking": true, "workingTime": 1670219812026, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE"}
```
Output of the Taker order
```
{ "symbol": "BTCUSDT", "orderId": 5, "orderListId": -1, "clientOrderId": "kocvDAi4GNN2y1l1Ojg1Ri", "price": "1.000000", "origQty": "3.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670219812046, "updateTime": 1670219812046, "isWorking": true, "workingTime": 1670219812046, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "EXPIRE_TAKER", "preventedMatchId": 0, "preventedQuantity": "3.000000"}
```
**Scenario D- A user has an order on the book, and then sends an order with `EXPIRE_BOTH` that would match with the existing order.**
```
Maker Order: symbol=BTCUSDT side=BUY type=LIMIT quantity=1 price=1 selfTradePreventionMode=NONETaker Order: symbol=BTCUSDT side=SELL type=LIMIT quantity=3 price=1 selfTradePreventionMode=EXPIRE_BOTH
```
**Result:** Both orders will expire.
Maker Order
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "2JPC8xjpLq6Q0665uYWAcs", "price": "1.000000", "origQty": "1.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1673842412831, "updateTime": 1673842413170, "isWorking": true, "workingTime": 1673842412831, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE", "preventedMatchId": 0, "preventedQuantity": "1.000000"}
```
Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 5, "orderListId": -1, "clientOrderId": "qMaz8yrOXk2iUIz74cFkiZ", "transactTime": 1673842413170, "price": "1.000000", "origQty": "3.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "workingTime": 1673842413170, "fills": [], "preventedMatches": [ { "preventedMatchId": 0, "makerOrderId": 2, "price": "1.000000", "takerPreventedQuantity": "3.000000", "makerPreventedQuantity": "1.000000" } ], "selfTradePreventionMode": "EXPIRE_BOTH", "tradeGroupId": 1, "preventedQuantity": "3.000000"}
```
**Scenario E - A user has an order on the book with `EXPIRE_MAKER`, and then sends a new order with `EXPIRE_TAKER` which would match with the existing order.**
```
Maker Order: symbol=BTCUSDT side=BUY type=LIMIT quantity=1 price=1 selfTradePreventionMode=EXPIRE_MAKERTaker Order: symbol=BTCUSDT side=SELL type=LIMIT quantity=1 price=1 selfTradePreventionMode=EXPIRE_TAKER
```
**Result**: The taker order's STP mode will be used, so the taker order will be expired.
Maker Order
```
{ "symbol": "BTCUSDT", "orderId": 0, "orderListId": -1, "clientOrderId": "jFUap8iFwwgqIpOfAL60GS", "price": "1.000000", "origQty": "1.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670220769261, "updateTime": 1670220769261, "isWorking": true, "workingTime": 1670220769261, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "EXPIRE_MAKER"}
```
Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 1, "orderListId": -1, "clientOrderId": "zxrvnNNm1RXC3rkPLUPrc1", "transactTime": 1670220800315, "price": "1.000000", "origQty": "1.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "workingTime": 1670220800315, "fills": [], "preventedMatches": [ { "preventedMatchId": 0, "makerOrderId": 0, "price": "1.000000", "takerPreventedQuantity": "1.000000" } ], "selfTradePreventionMode": "EXPIRE_TAKER", "preventedQuantity": "1.000000"}
```
**Scenario F - A user sends a market order with `EXPIRE_MAKER` which would match with an existing order.**
```
Maker Order: symbol=BTCUSDT side=BUY type=LIMIT quantity=1 price=1 selfTradePreventionMode=NONETaker Order: symbol=BTCUSDT side=SELL type=MARKET quantity=1 selfTradePreventionMode=EXPIRE_MAKER
```
**Result**: The existing order expires with the status `EXPIRED_IN_MATCH`, due to STP. The new order also expires but with status `EXPIRED`, due to low liquidity on the order book.
Maker Order
```
{ "symbol": "BTCUSDT", "orderId": 2, "orderListId": -1, "clientOrderId": "7sgrQQInL69XDMQpiqMaG2", "price": "1.000000", "origQty": "1.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.000000", "icebergQty": "0.000000", "time": 1670222557456, "updateTime": 1670222557478, "isWorking": true, "workingTime": 1670222557456, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE", "preventedMatchId": 0, "preventedQuantity": "1.000000"}
```
Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 3, "orderListId": -1, "clientOrderId": "zqhsgGDEcdhxy2oza2Ljxd", "transactTime": 1670222557478, "price": "0.000000", "origQty": "1.000000", "executedQty": "0.000000", "cummulativeQuoteQty": "0.000000", "status": "EXPIRED", "timeInForce": "GTC", "type": "MARKET", "side": "SELL", "workingTime": 1670222557478, "fills": [], "preventedMatches": [ { "preventedMatchId": 0, "makerOrderId": 2, "price": "1.000000", "makerPreventedQuantity": "1.000000" } ], "selfTradePreventionMode": "EXPIRE_MAKER"}
```
**Scenario G- A user sends a limit order with `DECREMENT` which would match with an existing order.**
```
Maker Order: symbol=BTCUSDT side=BUY type=LIMIT quantity=6 price=2 selfTradePreventionMode=NONETaker Order: symbol=BTCUSDT side=SELL type=LIMIT quantity=2 price=2 selfTradePreventionMode=DECREMENT
```
**Result**: Both orders have a preventedQuantity of 2. Since this is the taker orders full quantity, it expires due to STP.
Maker Order
```
{ "symbol": "BTCUSDT", "orderId": 23, "orderListId": -1, "clientOrderId": "Kxb4RpsBhfQrkK2r2YO2Z9", "price": "2.00000000", "origQty": "6.00000000", "executedQty": "0.00000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.00000000", "icebergQty": "0.00000000", "time": 1741682807892, "updateTime": 1741682816376, "isWorking": true, "workingTime": 1741682807892, "origQuoteOrderQty": "0.00000000", "selfTradePreventionMode": "DECREMENT", "preventedMatchId": 4, "preventedQuantity": "2.00000000"}
```
Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 24, "orderListId": -1, "clientOrderId": "dwf3qOzD7GM9ysDn9XG9AS", "price": "2.00000000", "origQty": "2.00000000", "executedQty": "0.00000000", "cummulativeQuoteQty": "0.00000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "stopPrice": "0.00000000", "icebergQty": "0.00000000", "time": 1741682816376, "updateTime": 1741682816376, "isWorking": true, "workingTime": 1741682816376, "origQuoteOrderQty": "0.00000000", "selfTradePreventionMode": "DECREMENT", "preventedMatchId": 4, "preventedQuantity": "2.00000000"}
```
**Scenario H- A user sends a limit order with `TRANSFER` which would match with an existing order under the same tradeGroupId.**
Balances before order placement
Maker's Balances
```
{ "balances": [ { "asset": "BTC", "free": "20000.00000000", "locked": "0.00000000" }, { "asset": "USDT", "free": "20000.00000000", "locked": "0.00000000" } ]}
```
Taker's Balances
```
{ "balances": [ { "asset": "BTC", "free": "20000.00000000", "locked": "0.00000000" }, { "asset": "USDT", "free": "20000.00000000", "locked": "0.00000000" } ]}
```
```
Maker Order: symbol=BTCUSDT side=BUY type=LIMIT quantity=0.6 price=0.2 selfTradePreventionMode=TRANSFER tradeGroupId=1Taker Order: symbol=BTCUSDT side=SELL type=LIMIT quantity=0.2 price=0.2 selfTradePreventionMode=TRANSFER tradeGroupId=1
```
**Result:** Both orders have a preventedQuantity of 0.2. Since this is the takers full quantity, it expires due to STP.
Maker Order
```
{ "symbol": "BTCUSDT", "orderId": 12, "orderListId": -1, "clientOrderId": "zEyu9HGqiT5YUaXXhKr1MR", "price": "0.20000000", "origQty": "0.60000000", "executedQty": "0.00000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.00000000", "icebergQty": "0.00000000", "time": 1762852466582, "updateTime": 1762852522145, "isWorking": true, "workingTime": 1762852466582, "origQuoteOrderQty": "0.00000000", "selfTradePreventionMode": "TRANSFER", "preventedMatchId": 3, "preventedQuantity": "0.20000000"}
```
Taker Order
```
{ "symbol": "BTCUSDT", "orderId": 13, "orderListId": -1, "clientOrderId": "6T06cph3Et2yFNnGpHdejh", "transactTime": 1762852522145, "price": "0.20000000", "origQty": "0.20000000", "executedQty": "0.00000000", "origQuoteOrderQty": "0.00000000", "cummulativeQuoteQty": "0.00000000", "status": "EXPIRED_IN_MATCH", "timeInForce": "GTC", "type": "LIMIT", "side": "SELL", "workingTime": 1762852522145, "fills": [], "preventedMatches": [ { "preventedMatchId": 3, "makerSymbol": "BTCUSDT", "makerOrderId": 12, "price": "0.20000000", "takerPreventedQuantity": "0.20000000", "makerPreventedQuantity": "0.20000000" } ], "selfTradePreventionMode": "TRANSFER", "tradeGroupId": 1, "preventedQuantity": "0.20000000"}
```
Balances after self-trade prevention:
Maker Balances
```
{ "balances": [ { "asset": "BTC", "free": "20000.20000000", "locked": "0.00000000" }, { "asset": "USDT", "free": "19999.88000000", "locked": "0.08000000" } ]}
```
Taker's Balances
```
{ "balances": [ { "asset": "BTC", "free": "19999.80000000", "locked": "0.00000000" }, { "asset": "USDT", "free": "20000.04000000", "locked": "0.00000000" } ]}
```
- [What is Self Trade Prevention?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [What defines a self-trade?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [What happens when STP is triggered?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [What is a Trade Group Id?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [What is a Prevented Match?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [What is "prevented quantity?"](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [How do I know which symbol uses STP?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [How do I know if an order expired due to STP?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
- [STP Examples](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq)
@@ -1,275 +0,0 @@
---
title: "Trailing Stop FAQ | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq"
fetched_at: "2026-02-26T10:38:08.171Z"
---
# Spot Trailing Stop order FAQ
### What is a trailing stop order?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Trailing stop is a type of contingent order with a dynamic trigger price influenced by price changes in the market. For the SPOT API, the change required to trigger order entry is specified in the `trailingDelta` parameter, and is defined in BIPS.
Intuitively, trailing stop orders allow unlimited price movement in a direction that is beneficial for the order, and limited movement in a detrimental direction.
Buy orders: _low_ prices are good. Unlimited price _decreases_ are allowed but the order will trigger after a price _increase_ of the supplied delta, relative to the _lowest_ trade price since submission.
Sell orders: _high_ prices are good. Unlimited price _increases_ are allowed but the order will trigger after a price _decrease_ of the supplied delta, relative to the _highest_ trade price since submission.
### What are BIPs?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Basis Points, also known as BIP or BIPS, are used to indicate a percentage change.
BIPS conversion reference:
BIPS
Percentage
Multiplier
1
0.01%
0.0001
10
0.1%
0.001
100
1%
0.01
1000
10%
0.1
For example, a `STOP_LOSS` `SELL` order with a `trailingDelta` of 100 is a trailing stop order which will be triggered after a price decrease of 1% from the highest price after placing the order.
### What order types can be trailing stop orders?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Trailing stop orders are supported for contingent orders such as `STOP_LOSS`, `STOP_LOSS_LIMIT`, `TAKE_PROFIT`, and `TAKE_PROFIT_LIMIT`.
OCO orders also support trailing stop orders in the contingent leg. In this scenario if the trailing stop condition is triggered, the limit leg of the OCO order will be canceled.
### How do I place a trailing stop order?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Trailing stop orders are entered the same way as regular `STOP_LOSS`, `STOP_LOSS_LIMIT`, `TAKE_PROFIT`, or `TAKE_PROFIT_LIMIT` orders, but with an additional `trailingDelta` parameter. This parameter must be within the range of the `TRAILING_DELTA` filter for that symbol.
Unlike regular contingent orders, the `stopPrice` parameter is optional for trailing stop orders. If it is provided then the order will only start tracking price changes after the `stopPrice` condition is met. If the `stopPrice` parameter is omitted then the order starts tracking price changes from the next trade.
### What kind of price changes will trigger my trailing stop order?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Trailing order type
Side
Stop price condition
Market price movement required to trigger
`TAKE_PROFIT`
SELL
market price >= stop price
_decrease_ from maximum
`TAKE_PROFIT_LIMIT`
SELL
market price >= stop price
_decrease_ from maximum
`STOP_LOSS`
SELL
market price <= stop price
_decrease_ from maximum
`STOP_LOSS_LIMIT`
SELL
market price <= stop price
_decrease_ from maximum
`STOP_LOSS`
BUY
market price >= stop price
_increase_ from minimum
`STOP_LOSS_LIMIT`
BUY
market price >= stop price
_increase_ from minimum
`TAKE_PROFIT`
BUY
market price <= stop price
_increase_ from minimum
`TAKE_PROFIT_LIMIT`
BUY
market price <= stop price
_increase_ from minimum
### How do I pass the `TRAILING_DELTA` filter?[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
For `STOP_LOSS` `BUY`, `STOP_LOSS_LIMIT` `BUY`, `TAKE_PROFIT` `SELL`, and `TAKE_PROFIT_LIMIT` `SELL` orders:
- `trailingDelta` >= `minTrailingAboveDelta`
- `trailingDelta` <= `maxTrailingAboveDelta`
For `STOP_LOSS` `SELL`, `STOP_LOSS_LIMIT` `SELL`, `TAKE_PROFIT` `BUY`, and `TAKE_PROFIT_LIMIT` `BUY` orders:
- `trailingDelta` >= `minTrailingBelowDelta`
- `trailingDelta` <= `maxTrailingBelowDelta`
### Trailing Stop Order Scenarios[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
#### Scenario A - Trailing Stop Loss Limit Buy Order[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
At `12:01:00` there is a trade at a price of 40,000 and a `STOP_LOSS_LIMIT` order is placed on the `BUY` side of the exchange. The order has of a `stopPrice` of 44,000, a `trailingDelta` of 500 (5%), and a limit `price` of 45,000.
Between `12:01:00` and `12:02:00` a series of linear trades lead to a decrease in last price, ending at 37,000. This is a price decrease of 7.5% or 750 BIPS, well exceeding the order's `trailingDelta`. However since the order has not started price tracking, the price movement is ignored and the order remains contingent.
Between `12:02:00` and `12:03:00` a series of linear trades lead to an increase in last price. When a trade is equal to, or surpasses, the `stopPrice` the order starts tracking price changes immediately; the first trade that meets this condition sets the "lowest price". In this case, the lowest price is 44,000 and if there is a 500 BIPS increase from 44,000 then the order will trigger. The series of linear trades continue to increase the last price, ending at 45,000.
Between `12:03:00` and `12:04:00` a series of linear trades lead to an increase in last price, ending at 46,000. This is an increase of ~454 BIPS from the order's previously noted lowest price, but it's not large enough to trigger the order.
Between `12:04:00` and `12:05:00` a series of linear trades lead to a decrease in last price, ending at 42,000. This is a decrease from the order's previously noted lowest price. If there is a 500 BIPS increase from 42,000 then the order will trigger.
Between `12:05:00` and `12:05:30` a series of linear trades lead to an increase in last price to 44,100. This trade is equal to, or surpasses, the order's requirement of 500 BIPS, as `44,100 = 42,000 * 1.05`. This causes the order to trigger and start working against the order book at its limit price of 45,000.
![image](https://user-images.githubusercontent.com/17701918/167370103-ab3b4c05-1e13-4a25-b99a-42f9e4d6adc8.png)
#### Scenario B - Trailing Stop Loss Limit Sell Order[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
At `12:01:00` there is a trade at a price of 40,000 and a `STOP_LOSS_LIMIT` order is placed on the `SELL` side of the exchange. The order has of a `stopPrice` of 39,000, a `trailingDelta` of 1000 (10%), and a limit `price` of 38,000.
Between `12:01:00` and `12:02:00` a series of linear trades lead to an increase in last price, ending at 41,500.
Between `12:02:00` and `12:03:00` a series of linear trades lead to a decrease in last price. When a trade is equal to, or surpasses, the `stopPrice` the order starts tracking price changes immediately; the first trade that meets this condition sets the "highest price". In this case, the highest price is 39,000 and if there is a 1000 BIPS decrease from 39,000 then the order will trigger.
Between `12:03:00` and `12:04:00` a series of linear trades lead to a decrease in last price, ending at 37,000. This is a decrease of ~512 BIPS from the order's previously noted highest price, but it's not large enough to trigger the order.
Between `12:04:00` and `12:05:00` a series of linear trades lead to an increase in last price, ending at 41,000. This is an increase from the order's previously noted highest price. If there is a 1000 BIPS decrease from 41,000 then the order will trigger.
Between `12:05:00` and `12:05:30` a series of linear trades lead to a decrease in last price to 36,900. This trade is equal to, or surpasses, the order's requirement of 1000 BIPS, as `36,900 = 41,000 * 0.90`. This causes the order to trigger and start working against the order book at its limit price of 38,000.
![image](https://user-images.githubusercontent.com/17701918/167370383-eb813cc1-d9b8-4a94-896c-a1a29551e09d.png)
#### Scenario C - Trailing Take Profit Limit Buy Order[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
At `12:01:00` there is a trade at a price of 40,000 and a `TAKE_PROFIT_LIMIT` order is placed on the `BUY` side of the exchange. The order has of a `stopPrice` of 38,000, a `trailingDelta` of 850 (8.5%), and a limit `price` of 38,500.
Between `12:01:00` and `12:02:00` a series of linear trades lead to an increase in last price, ending at 42,000.
Between `12:02:00` and `12:03:00` a series of linear trades lead to a decrease in last price. When a trade is equal to, or surpasses, the `stopPrice` the order starts tracking price changes immediately; the first trade that meets this condition sets the "lowest price". In this case, the lowest price is 38,000 and if there is a 850 BIPS increase from 38,000 then the order will trigger.
The series of linear trades continues to decrease the last price, ending at 37,000. If there is a 850 BIPS increase from 37,000 then the order will trigger.
Between `12:03:00` and `12:04:00` a series of linear trades lead to an increase in last price, ending at 39,000. This is an increase of ~540 BIPS from the order's previously noted lowest price, but it's not large enough to trigger the order.
Between `12:04:00` and `12:05:00` a series of linear trades lead to a decrease in last price, ending at 38,000. It does not surpass the order's previously noted lowest price, resulting in no change to the order's trigger price.
Between `12:05:00` and `12:05:30` a series of linear trades lead to an increase in last price to 40,145. This trade is equal to, or surpasses, the order's requirement of 850 BIPS, as `40,145 = 37,000 * 1.085`. This causes the order to trigger and start working against the order book at its limit price of 38,500.
![image](https://user-images.githubusercontent.com/17701918/167370339-f1b83c76-790b-4108-8c9a-db2d89a4850f.png)
#### Scenario D - Trailing Take Profit Limit Sell Order[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
At `12:01:00` there is a trade at a price of 40,000 and a `TAKE_PROFIT_LIMIT` order is placed on the `SELL` side of the exchange. The order has of a `stopPrice` of 42,000, a `trailingDelta` of 750 (7.5%), and a limit `price` of 41,000.
Between `12:01:00` and `12:02:00` a series of linear trades lead to an increase in last price, ending at 41,500.
Between `12:02:00` and `12:03:00` a series of linear trades lead to a decrease in last price, ending at 39,000.
Between `12:03:00` and `12:04:00` a series of linear trades lead to an increase in last price. When a trade is equal to, or surpasses, the `stopPrice` the order starts tracking price changes immediately; the first trade that meets this condition sets the "highest price". In this case, the highest price is 42,000 and if there is a 750 BIPS decrease from 42,000 then the order will trigger.
The series of linear trades continues to increase the last price, ending at 45,000. If there is a 750 BIPS decrease from 45,000 then the order will trigger.
Between `12:04:00` and `12:05:00` a series of linear trades lead to a decrease in last price, ending at 44,000. This is a decrease of ~222 BIPS from the order's previously noted highest price, but it's not large enough to trigger the order.
Between `12:05:00` and `12:06:00` a series of linear trades lead to an increase in last price, ending at 46,500. This is an increase from the order's previously noted highest price. If there is a 750 BIPS decrease from 46,500 then the order will trigger.
Between `12:06:00` and `12:06:50` a series of linear trades lead to a decrease in last price to 43,012.5. This trade is equal to, or surpasses, the order's requirement of 750 BIPS, as `43,012.5 = 46,500 * 0.925`. This causes the order to trigger and start working against the order book at its limit price of 41,000.
![image](https://user-images.githubusercontent.com/17701918/167370298-172b227a-198d-46ee-a385-5cc267dc253b.png)
#### Scenario E - Trailing Stop Order Without A Stop Price[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
At `12:01:00` there is a trade at a price of 40,000 and a `STOP_LOSS_LIMIT` order is placed on the `SELL` side of the exchange. The order has a `trailingDelta` of 700 (7%), a limit `price` of 39,000 and no `stopPrice`. The order starts tracking price changes once placed. If there is a 700 BIPS decrease from 40,000 then the order will trigger.
Between `12:01:00` and `12:02:00` a series of linear trades lead to an increase in last price, ending at 42,000. This is an increase from the order's previously noted highest price. If there is a 700 BIPS decrease from 42,000 then the order will trigger.
Between `12:02:00` and `12:03:00` a series of linear trades lead to a decrease in last price, ending at 39,500. This is a decrease of ~595 BIPS from the order's previously noted highest price, but it's not large enough to trigger the order.
Between `12:03:00` and `12:04:00` a series of linear trades lead to an increase in last price, ending at 45,500. This is an increase from the order's previously noted highest price. If there is a 700 BIPS decrease from 45,500 then the order will trigger.
Between `12:04:00` and `12:04:45` a series of linear trades lead to a decrease in last price to 42,315. This trade is equal to, or surpasses, the order's requirement of 700 BIPS, as `42,315 = 45,500 * 0.93`. This causes the order to trigger and start working against the order book at its limit price of 39,000.
![image](https://user-images.githubusercontent.com/17701918/167370616-17d3295a-3e7c-4314-aa13-ad44e685a311.png)
### Trailing Stop Order Examples[](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
Assuming a last price of 40,000.
Placing a trailing stop `STOP_LOSS_LIMIT BUY` order, with a price of 42,000.0 and a trailing stop of 5%.
```
# Excluding stop pricePOST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=STOP_LOSS_LIMIT&timeInForce=GTC&quantity=0.01&price=42000&trailingDelta=500&timestamp=<timestamp>&signature=<signature>'# Including stop price of 43,000POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=STOP_LOSS_LIMIT&timeInForce=GTC&quantity=0.01&price=42000&stopPrice=43000&trailingDelta=500&timestamp=<timestamp>&signature=<signature>'
```
Placing a trailing stop `STOP_LOSS_LIMIT SELL` order, with a price of 37,500.0 and a trailing stop of 2.5%.
```
# Excluding stop pricePOST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=SELL&type=STOP_LOSS_LIMIT&timeInForce=GTC&quantity=0.01&price=37500&trailingDelta=250&timestamp=<timestamp>&signature=<signature>'# Including stop price of 39,000POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=SELL&type=STOP_LOSS_LIMIT&timeInForce=GTC&quantity=0.01&price=37500&stopPrice=39000&trailingDelta=250&timestamp=<timestamp>&signature=<signature>'
```
Placing a trailing stop `TAKE_PROFIT_LIMIT BUY` order, with a price of 38,000.0 and a trailing stop of 5%.
```
# Excluding stop pricePOST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=TAKE_PROFIT_LIMIT&timeInForce=GTC&quantity=0.01&price=38000&trailingDelta=500&timestamp=<timestamp>&signature=<signature>'# Including stop price of 36,000POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=BUY&type=TAKE_PROFIT_LIMIT&timeInForce=GTC&quantity=0.01&price=38000&stopPrice=36000&trailingDelta=500&timestamp=<timestamp>&signature=<signature>'
```
Placing a trailing stop `TAKE_PROFIT_LIMIT SELL` order, with a price of 41,500.0 and a trailing stop of 1.75%.
```
# Excluding stop pricePOST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=SELL&type=TAKE_PROFIT_LIMIT&timeInForce=GTC&quantity=0.01&price=41500&trailingDelta=175&timestamp=<timestamp>&signature=<signature>'# Including stop price of 42,500POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=SELL&type=TAKE_PROFIT_LIMIT&timeInForce=GTC&quantity=0.01&price=41500&stopPrice=42500&trailingDelta=175&timestamp=<timestamp>&signature=<signature>'
```
- [What is a trailing stop order?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [What are BIPs?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [What order types can be trailing stop orders?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [How do I place a trailing stop order?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [What kind of price changes will trigger my trailing stop order?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [How do I pass the `TRAILING_DELTA` filter?](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [Trailing Stop Order Scenarios](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
- [Trailing Stop Order Examples](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq)
-324
View File
@@ -1,324 +0,0 @@
---
title: "Filters | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/filters"
fetched_at: "2026-02-26T10:38:08.277Z"
---
# Filters
Filters define trading rules on a symbol or an exchange. Filters come in three forms: `symbol filters`, `exchange filters` and `asset filters`.
## Symbol filters[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
### PRICE\_FILTER[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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` % `tickSize` == 0
**/exchangeInfo format:**
```
{ "filterType": "PRICE_FILTER", "minPrice": "0.00000100", "maxPrice": "100000.00000000", "tickSize": "0.00000100"}
```
### PERCENT\_PRICE[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `PERCENT_PRICE` filter defines the valid range for the 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:**
```
{ "filterType": "PERCENT_PRICE", "multiplierUp": "1.3000", "multiplierDown": "0.7000", "avgPriceMins": 5}
```
### PERCENT\_PRICE\_BY\_SIDE[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `PERCENT_PRICE_BY_SIDE` filter defines the valid range for the 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.
There is a different range depending on whether the order is placed on the `BUY` side or the `SELL` side.
Buy orders will succeed on this filter if:
- `Order price` <= `weightedAveragePrice` \* `bidMultiplierUp`
- `Order price` >= `weightedAveragePrice` \* `bidMultiplierDown`
Sell orders will succeed on this filter if:
- `Order Price` <= `weightedAveragePrice` \* `askMultiplierUp`
- `Order Price` >= `weightedAveragePrice` \* `askMultiplierDown`
**/exchangeInfo format:**
```
{ "filterType": "PERCENT_PRICE_BY_SIDE", "bidMultiplierUp": "1.2", "bidMultiplierDown": "0.2", "askMultiplierUp": "5", "askMultiplierDown": "0.8", "avgPriceMins": 1}
```
### LOT\_SIZE[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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` % `stepSize` == 0
**/exchangeInfo format:**
```
{ "filterType": "LOT_SIZE", "minQty": "0.00100000", "maxQty": "100000.00000000", "stepSize": "0.00100000"}
```
### MIN\_NOTIONAL[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `MIN_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 `MIN_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:**
```
{ "filterType": "MIN_NOTIONAL", "minNotional": "0.00100000", "applyToMarket": true, "avgPriceMins": 5}
```
### NOTIONAL[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `NOTIONAL` filter defines the acceptable notional range allowed for an order on a symbol.
`applyMinToMarket` determines whether the `minNotional` will be applied to `MARKET` orders.
`applyMaxToMarket` determines whether the `maxNotional` will be applied to `MARKET` orders.
In order to pass this filter, the notional (`price * quantity`) has to pass the following conditions:
- `price * quantity` <= `maxNotional`
- `price * quantity` >= `minNotional`
For `MARKET` orders, the average price used over the last `avgPriceMins` minutes will be used for calculation.
If the `avgPriceMins` is 0, then the last price will be used.
**/exchangeInfo format:**
```
{ "filterType": "NOTIONAL", "minNotional": "10.00000000", "applyMinToMarket": false, "maxNotional": "10000.00000000", "applyMaxToMarket": false, "avgPriceMins": 5}
```
### ICEBERG\_PARTS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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:**
```
{ "filterType": "ICEBERG_PARTS", "limit": 10}
```
### MARKET\_LOT\_SIZE[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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` % `stepSize` == 0
**/exchangeInfo format:**
```
{ "filterType": "MARKET_LOT_SIZE", "minQty": "0.00100000", "maxQty": "100000.00000000", "stepSize": "0.00100000"}
```
### MAX\_NUM\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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:**
```
{ "filterType": "MAX_NUM_ORDERS", "maxNumOrders": 25}
```
### MAX\_NUM\_ALGO\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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:**
```
{ "filterType": "MAX_NUM_ALGO_ORDERS", "maxNumAlgoOrders": 5}
```
### MAX\_NUM\_ICEBERG\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
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:**
```
{ "filterType": "MAX_NUM_ICEBERG_ORDERS", "maxNumIcebergOrders": 5}
```
### MAX\_POSITION[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `MAX_POSITION` 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:
1. free balance of the base asset
2. locked balance of the base asset
3. sum of the qty of all open BUY orders
`BUY` orders will be rejected if the account's position is greater than the maximum position allowed.
If an order's `quantity` can cause the position to overflow, this will also fail the `MAX_POSITION` filter.
**/exchangeInfo format:**
```
{ "filterType": "MAX_POSITION", "maxPosition": "10.00000000"}
```
### TRAILING\_DELTA[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `TRAILING_DELTA` filter defines the minimum and maximum value for the parameter [`trailingDelta`](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq).
In order for a trailing stop order to pass this filter, the following must be true:
For `STOP_LOSS BUY`, `STOP_LOSS_LIMIT_BUY`,`TAKE_PROFIT SELL` and `TAKE_PROFIT_LIMIT SELL` orders:
- `trailingDelta` >= `minTrailingAboveDelta`
- `trailingDelta` <= `maxTrailingAboveDelta`
For `STOP_LOSS SELL`, `STOP_LOSS_LIMIT SELL`, `TAKE_PROFIT BUY`, and `TAKE_PROFIT_LIMIT BUY` orders:
- `trailingDelta` >= `minTrailingBelowDelta`
- `trailingDelta` <= `maxTrailingBelowDelta`
**/exchangeInfo format:**
```
{ "filterType": "TRAILING_DELTA", "minTrailingAboveDelta": 10, "maxTrailingAboveDelta": 2000, "minTrailingBelowDelta": 10, "maxTrailingBelowDelta": 2000}
```
### MAX\_NUM\_ORDER\_AMENDS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `MAX_NUM_ORDER_AMENDS` filter defines the maximum number of times an order can be amended on the given symbol.
If there are too many order amendments made on a single order, you will receive the `-2038` error code.
**/exchangeInfo format:**
```
{ "filterType": "MAX_NUM_ORDER_AMENDS", "maxNumOrderAmends": 10}
```
### MAX\_NUM\_ORDER\_LISTS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `MAX_NUM_ORDER_LISTS` filter defines the maximum number of open order lists an account can have on a symbol. Note that OTOCOs count as one order list.
**/exchangeInfo format:**
```
{ "filterType": "MAX_NUM_ORDER_LISTS", "maxNumOrderLists": 20}
```
## Exchange Filters[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
### EXCHANGE\_MAX\_NUM\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `EXCHANGE_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:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ORDERS", "maxNumOrders": 1000}
```
### EXCHANGE\_MAX\_NUM\_ALGO\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `EXCHANGE_MAX_NUM_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:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ALGO_ORDERS", "maxNumAlgoOrders": 200}
```
### EXCHANGE\_MAX\_NUM\_ICEBERG\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `EXCHANGE_MAX_NUM_ICEBERG_ORDERS` filter defines the maximum number of iceberg orders an account is allowed to have open on the exchange.
**/exchangeInfo format:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ICEBERG_ORDERS", "maxNumIcebergOrders": 10000}
```
### EXCHANGE\_MAX\_NUM\_ORDER\_LISTS[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `EXCHANGE_MAX_NUM_ORDERS` filter defines the maximum number of order lists an account is allowed to have open on the exchange. Note that OTOCOs count as one order list.
**/exchangeInfo format:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ORDER_LISTS", "maxNumOrderLists": 20}
```
## Asset Filters[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
### MAX\_ASSET[](https://developers.binance.com/docs/binance-spot-api-docs/filters)
The `MAX_ASSET` filter defines the maximum quantity of an asset that an account is allowed to transact in a single order.
- When the asset is a symbol's base asset, the limit applies to the order's quantity.
- When the asset is a symbol's quote asset, the limit applies to the order's notional value.
- For example, a MAX\_ASSET filter for USDC applies to all symbols that have USDC as either a base or quote asset, such as:
- USDCBNB
- BNBUSDC
**/myFilters format:**
```
{ "filterType": "MAX_ASSET", "asset": "USDC", "limit": "42.00000000"}
```
- [Symbol filters](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [PRICE\_FILTER](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [PERCENT\_PRICE](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [PERCENT\_PRICE\_BY\_SIDE](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [LOT\_SIZE](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MIN\_NOTIONAL](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [NOTIONAL](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [ICEBERG\_PARTS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MARKET\_LOT\_SIZE](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_NUM\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_NUM\_ALGO\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_NUM\_ICEBERG\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_POSITION](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [TRAILING\_DELTA](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_NUM\_ORDER\_AMENDS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_NUM\_ORDER\_LISTS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [Exchange Filters](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [EXCHANGE\_MAX\_NUM\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [EXCHANGE\_MAX\_NUM\_ALGO\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [EXCHANGE\_MAX\_NUM\_ICEBERG\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [EXCHANGE\_MAX\_NUM\_ORDER\_LISTS](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [Asset Filters](https://developers.binance.com/docs/binance-spot-api-docs/filters)
- [MAX\_ASSET](https://developers.binance.com/docs/binance-spot-api-docs/filters)
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
@@ -1,2 +0,0 @@
URL: https://developers.binance.com/docs/binance-spot-api-docs/rest-api.md
Error: 404
@@ -1,976 +0,0 @@
---
title: "Account Endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints"
fetched_at: "2026-02-26T10:38:08.458Z"
---
### Account information (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/account
```
Get current account information.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
omitZeroBalances
BOOLEAN
NO
When set to `true`, emits only the non-zero balances of an account.
Default value: `false`
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Memory => Database
**Response:**
```
{ "makerCommission": 15, "takerCommission": 15, "buyerCommission": 0, "sellerCommission": 0, "commissionRates": { "maker": "0.00150000", "taker": "0.00150000", "buyer": "0.00000000", "seller": "0.00000000" }, "canTrade": true, "canWithdraw": true, "canDeposit": true, "brokered": false, "requireSelfTradePrevention": false, "preventSor": false, "updateTime": 123456789, "accountType": "SPOT", "balances": [ { "asset": "BTC", "free": "4723846.89208129", "locked": "0.00000000" }, { "asset": "LTC", "free": "4763368.68006011", "locked": "0.00000000" } ], "permissions": ["SPOT"], "uid": 354937868}
```
### Query order (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/order
```
Check an order's status.
**Weight:** 4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
NO
origClientOrderId
STRING
NO
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Notes:**
- Either `orderId` or `origClientOrderId` must be sent.
- If both `orderId` and `origClientOrderId` are provided, the `orderId` is searched first, then the `origClientOrderId` from that result is checked against that order. If both conditions are not met the request will be rejected.
- For some historical orders `cummulativeQuoteQty` will be < 0, meaning the data is not available at this time.
**Data Source:** Memory => Database
**Response:**
```
{ "symbol": "LTCBTC", "orderId": 1, "orderListId": -1, // This field will always have a value of -1 if not an order list. "clientOrderId": "myOrder1", "price": "0.1", "origQty": "1.0", "executedQty": "0.0", "cummulativeQuoteQty": "0.0", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.0", "icebergQty": "0.0", "time": 1499827319559, "updateTime": 1499827319559, "isWorking": true, "workingTime": 1499827319559, "origQuoteOrderQty": "0.000000", "selfTradePreventionMode": "NONE"}
```
**Note:** The payload above does not show all fields that can appear. Please refer to [Conditional fields in Order Responses](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/trading-endpoints).
### Current open orders (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/openOrders
```
Get all open orders on a symbol. **Careful** when accessing this with no symbol.
**Weight:** 6 for a single symbol; **80** when the symbol parameter is omitted
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
- If the symbol is not sent, orders for all symbols will be returned in an array.
**Data Source:** Memory => Database
**Response:**
```
[ { "symbol": "LTCBTC", "orderId": 1, "orderListId": -1, // Unless it's part of an order list, value will be -1 "clientOrderId": "myOrder1", "price": "0.1", "origQty": "1.0", "executedQty": "0.0", "cummulativeQuoteQty": "0.0", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.0", "icebergQty": "0.0", "time": 1499827319559, "updateTime": 1499827319559, "isWorking": true, "origQuoteOrderQty": "0.000000", "workingTime": 1499827319559, "selfTradePreventionMode": "NONE" }]
```
**Note:** The payload above does not show all fields that can appear. Please refer to [Conditional fields in Order Responses](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/trading-endpoints).
### All orders (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/allOrders
```
Get all account orders; active, canceled, or filled.
**Weight:** 20
**Data Source:** Database
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
NO
startTime
LONG
NO
endTime
LONG
NO
limit
INT
NO
Default: 500; Maximum: 1000.
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Notes:**
- If `orderId` is set, it will get orders >= that `orderId`. Otherwise most recent orders are returned.
- For some historical orders `cummulativeQuoteQty` will be < 0, meaning the data is not available at this time.
- If `startTime` and/or `endTime` provided, `orderId` is not required.
- The time between `startTime` and `endTime` can't be longer than 24 hours.
**Response:**
```
[ { "symbol": "LTCBTC", "orderId": 1, "orderListId": -1, // Unless it's part of an order list, value will be -1 "clientOrderId": "myOrder1", "price": "0.1", "origQty": "1.0", "executedQty": "0.0", "cummulativeQuoteQty": "0.0", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.0", "icebergQty": "0.0", "time": 1499827319559, "updateTime": 1499827319559, "isWorking": true, "origQuoteOrderQty": "0.000000", "workingTime": 1499827319559, "selfTradePreventionMode": "NONE" }]
```
**Note:** The payload above does not show all fields that can appear. Please refer to [Conditional fields in Order Responses](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/trading-endpoints).
### Query Order list (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/orderList
```
Retrieves a specific order list based on provided optional parameters.
**Weight:** 4
**Parameters:**
Name
Type
Mandatory
Description
orderListId
LONG
NO\*
Query order list by `orderListId`.
`orderListId` or `origClientOrderId` must be provided.
origClientOrderId
STRING
NO\*
Query order list by `listClientOrderId`.
`orderListId` or `origClientOrderId` must be provided.
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Database
**Response:**
```
{ "orderListId": 27, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "h2USkA5YQpaXHPIrkd96xE", "transactionTime": 1565245656253, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 4, "clientOrderId": "qD1gy3kc3Gx0rihm9Y3xwS" }, { "symbol": "LTCBTC", "orderId": 5, "clientOrderId": "ARzZ9I00CPM8i3NhmU9Ega" } ]}
```
### Query all Order lists (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/allOrderList
```
Retrieves all order lists based on provided optional parameters.
Note that the time between `startTime` and `endTime` can't be longer than 24 hours.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
fromId
LONG
NO
If supplied, neither `startTime` or `endTime` can be provided
startTime
LONG
NO
endTime
LONG
NO
limit
INT
NO
Default: 500; Maximum: 1000
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Database
**Response:**
```
[ { "orderListId": 29, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "amEEAXryFzFwYF1FeRpUoZ", "transactionTime": 1565245913483, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 4, "clientOrderId": "oD7aesZqjEGlZrbtRpy5zB" }, { "symbol": "LTCBTC", "orderId": 5, "clientOrderId": "Jr1h6xirOxgeJOUuYQS7V3" } ] }, { "orderListId": 28, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "hG7hFNxJV6cZy3Ze4AUT4d", "transactionTime": 1565245913407, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 2, "clientOrderId": "j6lFOfbmFMRjTYA7rRJ0LP" }, { "symbol": "LTCBTC", "orderId": 3, "clientOrderId": "z0KCjOdditiLS5ekAFtK81" } ] }]
```
### Query Open Order lists (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/openOrderList
```
**Weight:** 6
**Parameters:**
Name
Type
Mandatory
Description
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Database
**Response:**
```
[ { "orderListId": 31, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "wuB13fmulKj3YjdqWEcsnp", "transactionTime": 1565246080644, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 4, "clientOrderId": "r3EH2N76dHfLoSZWIUw1bT" }, { "symbol": "LTCBTC", "orderId": 5, "clientOrderId": "Cv1SnyPD3qhqpbjpYEHbd2" } ] }]
```
### Account trade list (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/myTrades
```
Get trades for a specific account and symbol.
**Weight:**
Condition
Weight
Without orderId
20
With orderId
5
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
NO
This can only be used in combination with `symbol`.
startTime
LONG
NO
endTime
LONG
NO
fromId
LONG
NO
TradeId to fetch from. Default gets most recent trades.
limit
INT
NO
Default: 500; Maximum: 1000.
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Notes:**
- If `fromId` is set, it will get trades >= that `fromId`. Otherwise most recent trades are returned.
- The time between `startTime` and `endTime` can't be longer than 24 hours.
- These are the supported combinations of all parameters:
- `symbol`
- `symbol` + `orderId`
- `symbol` + `startTime`
- `symbol` + `endTime`
- `symbol` + `fromId`
- `symbol` + `startTime` + `endTime`
- `symbol`\+ `orderId` + `fromId`
**Data Source:** Memory => Database
**Response:**
```
[ { "symbol": "BNBBTC", "id": 28457, "orderId": 100234, "orderListId": -1, "price": "4.00000100", "qty": "12.00000000", "quoteQty": "48.000012", "commission": "10.10000000", "commissionAsset": "BNB", "time": 1499865549590, "isBuyer": true, "isMaker": false, "isBestMatch": true }]
```
### Query Unfilled Order Count (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/rateLimit/order
```
Displays the user's unfilled order count for all intervals.
**Weight:** 40
**Parameters:**
Name
Type
Mandatory
Description
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Memory
**Response:**
```
[ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 0 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 0 }]
```
### Query Prevented Matches (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/myPreventedMatches
```
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`
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
preventedMatchId
LONG
NO
orderId
LONG
NO
fromPreventedMatchId
LONG
NO
limit
INT
NO
Default: `500`; Maximum: `1000`
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Weight:**
Case
Weight
If `symbol` is invalid
2
Querying by `preventedMatchId`
2
Querying by `orderId`
20
**Data Source:**
Database
**Response:**
```
[ { "symbol": "BTCUSDT", "preventedMatchId": 1, "takerOrderId": 5, "makerSymbol": "BTCUSDT", "makerOrderId": 3, "tradeGroupId": 1, "selfTradePreventionMode": "EXPIRE_MAKER", "price": "1.100000", "makerPreventedQuantity": "1.300000", "transactTime": 1669101687094 }]
```
### Query Allocations (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/myAllocations
```
Retrieves allocations resulting from SOR order placement.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
Yes
startTime
LONG
No
endTime
LONG
No
fromAllocationId
INT
No
limit
INT
No
Default: 500; Maximum: 1000
orderId
LONG
No
recvWindow
DECIMAL
No
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
No
Supported parameter combinations:
Parameters
Response
`symbol`
allocations from oldest to newest
`symbol` + `startTime`
oldest allocations since `startTime`
`symbol` + `endTime`
newest allocations until `endTime`
`symbol` + `startTime` + `endTime`
allocations within the time range
`symbol` + `fromAllocationId`
allocations by allocation ID
`symbol` + `orderId`
allocations related to an order starting with oldest
`symbol` + `orderId` + `fromAllocationId`
allocations related to an order by allocation ID
**Note:** The time between `startTime` and `endTime` can't be longer than 24 hours.
**Data Source:** Database
**Response:**
```
[ { "symbol": "BTCUSDT", "allocationId": 0, "allocationType": "SOR", "orderId": 1, "orderListId": -1, "price": "1.00000000", "qty": "5.00000000", "quoteQty": "5.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "time": 1687506878118, "isBuyer": true, "isMaker": false, "isAllocator": false }]
```
### Query Commission Rates (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/account/commission
```
Get current account commission rates.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
**Data Source:** Database
**Response:**
```
{ "symbol": "BTCUSDT", "standardCommission": { // Commission rates on trades from the order. "maker": "0.00000010", "taker": "0.00000020", "buyer": "0.00000030", "seller": "0.00000040" }, "specialCommission": { // Special commission rates from the order. "maker": "0.01000000", "taker": "0.02000000", "buyer": "0.03000000", "seller": "0.04000000" }, "taxCommission": { // Tax commission rates for trades from the order. "maker": "0.00000112", "taker": "0.00000114", "buyer": "0.00000118", "seller": "0.00000116" }, "discount": { // Discount commission when paying in BNB "enabledForAccount": true, "enabledForSymbol": true, "discountAsset": "BNB", "discount": "0.75000000" // Standard commission is reduced by this rate when paying commission in BNB. }}
```
### Query Order Amendments (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/order/amendments
```
Queries all amendments of a single order.
**Weight**: 4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
YES
fromExecutionId
LONG
NO
limit
LONG
NO
Default:500; Maximum: 1000
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:**
Database
**Response:**
```
[ { "symbol": "BTCUSDT", "orderId": 9, "executionId": 22, "origClientOrderId": "W0fJ9fiLKHOJutovPK3oJp", "newClientOrderId": "UQ1Np3bmQ71jJzsSDW9Vpi", "origQty": "5.00000000", "newQty": "4.00000000", "time": 1741669661670 }, { "symbol": "BTCUDST", "orderId": 9, "executionId": 25, "origClientOrderId": "UQ1Np3bmQ71jJzsSDW9Vpi", "newClientOrderId": "5uS0r35ohuQyDlCzZuYXq2", "origQty": "4.00000000", "newQty": "3.00000000", "time": 1741672924895 }]
```
### Query relevant filters (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
```
GET /api/v3/myFilters
```
Retrieves the list of [filters](https://developers.binance.com/docs/binance-spot-api-docs/filters) relevant to an account on a given symbol. This is the only endpoint that shows if an account has [`MAX_ASSET`](https://developers.binance.com/docs/binance-spot-api-docs/filters) filters applied to it.
**Weight:** 40
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Memory
**Response:**
```
{ "exchangeFilters": [ { "filterType": "EXCHANGE_MAX_NUM_ORDERS", "maxNumOrders": 1000 } ], "symbolFilters": [ { "filterType": "MAX_NUM_ORDER_LISTS", "maxNumOrderLists": 20 } ], "assetFilters": [ { "filterType": "MAX_ASSET", "asset": "JPY", "limit": "1000000.00000000" } ]}
```
- [Account information (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query order (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Current open orders (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [All orders (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Order list (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query all Order lists (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Open Order lists (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Account trade list (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Unfilled Order Count (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Prevented Matches (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Allocations (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Commission Rates (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query Order Amendments (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Query relevant filters (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
@@ -1,15 +0,0 @@
---
title: "Data Sources | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/data-sources"
fetched_at: "2026-02-26T10:38:08.532Z"
---
- The API system is asynchronous, so some delay in the response is normal and expected.
- Each endpoint has a data source indicating where the data is being retrieved, and thus which endpoints have the most up-to-date response.
These are the three sources, ordered by least to most potential for delays in data updates.
- **Matching Engine** - the data is from the Matching Engine
- **Memory** - the data is from a server's local or external memory
- **Database** - the data is taken directly from a database
Some endpoints can have more than 1 data source. (e.g. Memory => Database) This means that the endpoint will check the first Data Source, and if it cannot find the value it's looking for it will check the next one.
@@ -1,14 +0,0 @@
---
title: "Error Codes | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/error-codes"
fetched_at: "2026-02-26T10:38:08.716Z"
---
- Any endpoint can return an ERROR
Sample Payload below:
```
{ "code": -1121, "msg": "Invalid symbol."}
```
- Specific error codes and messages are defined in [Errors Codes](https://developers.binance.com/docs/binance-spot-api-docs/errors).
@@ -1,32 +0,0 @@
---
title: "General API Information | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-api-information"
fetched_at: "2026-02-26T10:38:08.655Z"
---
- The following base endpoints are available. Please use whichever works best for your setup:
- **[https://api.binance.com](https://api.binance.com/)**
- **[https://api-gcp.binance.com](https://api-gcp.binance.com/)**
- **[https://api1.binance.com](https://api1.binance.com/)**
- **[https://api2.binance.com](https://api2.binance.com/)**
- **[https://api3.binance.com](https://api3.binance.com/)**
- **[https://api4.binance.com](https://api4.binance.com/)**
- The last 4 endpoints in the point above (`api1`\-`api4`) should give better performance but have less stability.
- Responses are in JSON by default. To receive responses in SBE, refer to the [SBE FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) page.
- If your request contains a symbol name containing non-ASCII characters, then the response may contain non-ASCII characters encoded in UTF-8.
- Some endpoints may return asset and/or symbol names containing non-ASCII characters encoded in UTF-8 even if the request did not contain non-ASCII characters.
- Data is returned in **chronological order**, unless noted otherwise.
- Without `startTime` or `endTime`, returns the most recent items up to the limit.
- With `startTime`, returns oldest items from `startTime` up to the limit.
- With `endTime`, returns most recent items up to `endTime` and the limit.
- With both, behaves like `startTime` but does not exceed `endTime`.
- All time and timestamp related fields in the JSON responses are in **milliseconds by default.** To receive the information in microseconds, please add the header `X-MBX-TIME-UNIT:MICROSECOND` or `X-MBX-TIME-UNIT:microsecond`.
- We support HMAC, RSA, and Ed25519 keys. For more information, please see [API Key types](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types).
- Timestamp parameters (e.g. `startTime`, `endTime`, `timestamp`) can be passed in milliseconds or microseconds.
- For APIs that only send public market data, please use the base endpoint **[https://data-api.binance.vision](https://data-api.binance.vision/)**. Please refer to [Market Data Only](https://developers.binance.com/docs/binance-spot-api-docs/faqs/market_data_only) page.
- If there are enums or terms you want clarification on, please see the [SPOT Glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary) for more information.
- APIs have a timeout of 10 seconds when processing a request. If a response from the Matching Engine takes longer than this, the API responds with "Timeout waiting for response from backend server. Send status unknown; execution status unknown." [(-1007 TIMEOUT)](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This does not always mean that the request failed in the Matching Engine.
- If the status of the request has not appeared in [User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream), please perform an API query for its status.
- **Please avoid SQL keywords in requests** as they may trigger a security block by a WAF (Web Application Firewall) rule. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
- If your request contains a symbol name containing non-ASCII characters, then the response may contain non-ASCII characters encoded in UTF-8.
- Some endpoints may return asset and/or symbol names containing non-ASCII characters encoded in UTF-8 even if the request did not contain non-ASCII characters.
@@ -1,137 +0,0 @@
---
title: "General endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints"
fetched_at: "2026-02-26T10:38:08.963Z"
---
### Test connectivity[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
```
GET /api/v3/ping
```
Test connectivity to the Rest API.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{}
```
### Check server time[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
```
GET /api/v3/time
```
Test connectivity to the Rest API and get the current server time.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "serverTime": 1499827319559}
```
### Exchange information[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
```
GET /api/v3/exchangeInfo
```
Current exchange trading rules and symbol information
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
No
Example: curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?symbol=BNBBTC](https://api.binance.com/api/v3/exchangeInfo?symbol=BNBBTC)"
symbols
ARRAY OF STRING
No
Examples: curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?symbols=%5B%22BNBBTC%22,%22BTCUSDT%22%5D](https://api.binance.com/api/v3/exchangeInfo?symbols=%5B%22BNBBTC%22,%22BTCUSDT%22%5D)"
or
curl -g -X GET '[https://api.binance.com/api/v3/exchangeInfo?symbols=\["BTCUSDT","BNBBTC](https://api.binance.com/api/v3/exchangeInfo?symbols=%5B%22BTCUSDT%22,%22BNBBTC)"\]'
permissions
ENUM
No
Examples: curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?permissions=SPOT](https://api.binance.com/api/v3/exchangeInfo?permissions=SPOT)"
or
curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?permissions=%5B%22MARGIN%22%2C%22LEVERAGED%22%5D](https://api.binance.com/api/v3/exchangeInfo?permissions=%5B%22MARGIN%22%2C%22LEVERAGED%22%5D)"
or
curl -g -X GET '[https://api.binance.com/api/v3/exchangeInfo?permissions=\["MARGIN","LEVERAGED](https://api.binance.com/api/v3/exchangeInfo?permissions=%5B%22MARGIN%22,%22LEVERAGED)"\]'
showPermissionSets
BOOLEAN
No
Controls whether the content of the `permissionSets` field is populated or not. Defaults to `true`
symbolStatus
ENUM
No
Filters for symbols that have this `tradingStatus`. Valid values: `TRADING`, `HALT`, `BREAK`
Cannot be used in combination with `symbols` or `symbol`.
**Notes:**
- If the value provided to `symbol` or `symbols` do not exist, the endpoint will throw an error saying the symbol is invalid.
- All parameters are optional.
- `permissions` can support single or multiple values (e.g. `SPOT`, `["MARGIN","LEVERAGED"]`). This cannot be used in combination with `symbol` or `symbols`.
- If `permissions` parameter not provided, all symbols that have either `SPOT`, `MARGIN`, or `LEVERAGED` permission will be exposed.
- To display symbols with any permission you need to specify them explicitly in `permissions`: (e.g. `["SPOT","MARGIN",...]`.). See [Account and Symbol Permissions](https://developers.binance.com/docs/binance-spot-api-docs/enums) for the full list.
**Examples of Symbol Permissions Interpretation from the Response:**
- `[["A","B"]]` means you may place an order if your account has either permission "A" **or** permission "B".
- `[["A"],["B"]]` means you can place an order if your account has permission "A" **and** permission "B".
- `[["A"],["B","C"]]` means you can place an order if your account has permission "A" **and** permission "B" or permission "C". (Inclusive or is applied here, not exclusive or, so your account may have both permission "B" and permission "C".)
**Data Source:** Memory
**Response:**
```
{ "timezone": "UTC", "serverTime": 1565246363776, "rateLimits": [ { // These are defined in the `ENUM definitions` section under `Rate Limiters (rateLimitType)`. // All limits are optional } ], "exchangeFilters": [ // These are the defined filters in the `Filters` section. // All filters are optional. ], "symbols": [ { "symbol": "ETHBTC", "status": "TRADING", "baseAsset": "ETH", "baseAssetPrecision": 8, "quoteAsset": "BTC", "quotePrecision": 8, // will be removed in future api versions (v4+) "quoteAssetPrecision": 8, "baseCommissionPrecision": 8, "quoteCommissionPrecision": 8, "orderTypes": [ "LIMIT", "LIMIT_MAKER", "MARKET", "STOP_LOSS", "STOP_LOSS_LIMIT", "TAKE_PROFIT", "TAKE_PROFIT_LIMIT" ], "icebergAllowed": true, "ocoAllowed": true, "otoAllowed": true, "opoAllowed": true, "quoteOrderQtyMarketAllowed": true, "allowTrailingStop": false, "cancelReplaceAllowed": false, "amendAllowed": false, "pegInstructionsAllowed": true, "isSpotTradingAllowed": true, "isMarginTradingAllowed": true, "filters": [ // These are defined in the Filters section. // All filters are optional ], "permissions": [], "permissionSets": [["SPOT", "MARGIN"]], "defaultSelfTradePreventionMode": "NONE", "allowedSelfTradePreventionModes": ["NONE"] } ], // Optional field. Present only when SOR is available. // https://github.com/binance/binance-spot-api-docs/blob/master/faqs/sor_faq.md "sors": [ { "baseAsset": "BTC", "symbols": ["BTCUSDT", "BTCUSDC"] } ]}
```
- [Test connectivity](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
- [Check server time](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
- [Exchange information](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-endpoints)
@@ -1,9 +0,0 @@
---
title: "General Information on Endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/general-information-on-endpoints"
fetched_at: "2026-02-26T10:38:08.909Z"
---
- For `GET` endpoints, parameters must be sent as a `query string`.
- For `POST`, `PUT`, and `DELETE` 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 `query string` parameter will be used.
@@ -1,11 +0,0 @@
---
title: "HTTP Return Codes | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/http-return-codes"
fetched_at: "2026-02-26T10:38:08.904Z"
---
- HTTP `4XX` return codes are used for malformed requests; the issue is on the sender's side.
- HTTP `403` return code is used when a WAF (Web Application Firewall) rule has been violated. This can indicate a rate limit violation or a security block. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
- HTTP `409` return code is used when a cancelReplace order partially succeeds. (i.e. if the cancellation of the order fails but the new order placement succeeds.)
- 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 Binance's side. It is important to **NOT** treat this as a failure operation; the execution status is **UNKNOWN** and could have been a success.
@@ -1,39 +0,0 @@
---
title: "LIMITS | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits"
fetched_at: "2026-02-26T10:38:08.971Z"
---
### General Info on Limits[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/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".
- The `/api/v3/exchangeInfo` `rateLimits` array contains objects related to the exchange's `RAW_REQUESTS`, `REQUEST_WEIGHT`, and `ORDERS` rate limits. These are further defined in the `ENUM definitions` section under `Rate limiters (rateLimitType)`.
- Requests fail with HTTP status code 429 when you exceed the request rate limit.
### IP Limits[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/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 429, to prevent a ban, or, in the case of a 418, until the ban is over.
- **The limits on the API are based on the IPs, not the API keys.**
### Unfilled Order Count[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits)
- Every successful order response will contain a `X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter)` header indicating how many orders you have placed for that interval.
To monitor this, refer to [`GET api/v3/rateLimit/order`](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints).
- Rejected/unsuccessful orders are not guaranteed to have `X-MBX-ORDER-COUNT-**` headers in the response.
- If you have exceeded this, you will receive a 429 error with the `Retry-After` header.
- **Please note that if your orders are consistently filled by trades, you can continuously place orders on the API**. For more information, please see [Spot Unfilled Order Count Rules](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement).
- **The number of unfilled orders is tracked for each account.**
- [General Info on Limits](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits)
- [IP Limits](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits)
- [Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/limits)
@@ -1,981 +0,0 @@
---
title: "Market Data endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints"
fetched_at: "2026-02-26T10:38:09.201Z"
---
### Order book[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/depth
```
**Weight:** Adjusted based on the limit:
Limit
Request Weight
1-100
5
101-500
25
501-1000
50
1001-5000
250
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
limit
INT
NO
Default: 100; Maximum: 5000.
If limit > 5000, only 5000 entries will be returned.
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
A status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response:**
```
{ "lastUpdateId": 1027024, "bids": [ [ "4.00000000", // PRICE "431.00000000" // QTY ] ], "asks": [["4.00000200", "12.00000000"]]}
```
### Recent trades list[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/trades
```
Get recent trades.
**Weight:** 25
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
limit
INT
NO
Default: 500; Maximum: 1000.
**Data Source:** Memory
**Response:**
```
[ { "id": 28457, "price": "4.00000100", "qty": "12.00000000", "quoteQty": "48.000012", "time": 1499865549590, "isBuyerMaker": true, "isBestMatch": true }]
```
### Old trade lookup[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/historicalTrades
```
Get older trades.
**Weight:** 25
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
limit
INT
NO
Default: 500; Maximum: 1000.
fromId
LONG
NO
TradeId to fetch from. Default gets most recent trades.
**Data Source:** Database
**Response:**
```
[ { "id": 28457, "price": "4.00000100", "qty": "12.00000000", "quoteQty": "48.000012", "time": 1499865549590, "isBuyerMaker": true, "isBestMatch": true }]
```
### Compressed/Aggregate trades list[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/aggTrades
```
Get compressed, aggregate trades. Trades that fill at the time, from the same taker order, with the same price will have the quantity aggregated.
**Weight:** 4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
fromId
LONG
NO
ID to get aggregate trades from INCLUSIVE.
startTime
LONG
NO
Timestamp in ms to get aggregate trades from INCLUSIVE.
endTime
LONG
NO
Timestamp in ms to get aggregate trades until INCLUSIVE.
limit
INT
NO
Default: 500; Maximum: 1000.
- If fromId, startTime, and endTime are not sent, the most recent aggregate trades will be returned.
**Data Source:** Database
**Response:**
```
[ { "a": 26129, // Aggregate tradeId "p": "0.01633102", // Price "q": "4.70443515", // Quantity "f": 27781, // First tradeId "l": 27781, // Last tradeId "T": 1498793709153, // Timestamp "m": true, // Was the buyer the maker? "M": true // Was the trade the best price match? }]
```
### Kline/Candlestick data[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/klines
```
Kline/candlestick bars for a symbol. Klines are uniquely identified by their open time.
**Weight:** 2
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
interval
ENUM
YES
startTime
LONG
NO
endTime
LONG
NO
timeZone
STRING
NO
Default: 0 (UTC)
limit
INT
NO
Default: 500; Maximum: 1000.
Supported kline intervals (case-sensitive):
Interval
`interval` value
seconds
`1s`
minutes
`1m`, `3m`, `5m`, `15m`, `30m`
hours
`1h`, `2h`, `4h`, `6h`, `8h`, `12h`
days
`1d`, `3d`
weeks
`1w`
months
`1M`
**Notes:**
- If `startTime` and `endTime` are not sent, the most recent klines are returned.
- Supported values for `timeZone`:
- Hours and minutes (e.g. `-1:00`, `05:45`)
- Only hours (e.g. `0`, `8`, `4`)
- Accepted range is strictly \[-12:00 to +14:00\] inclusive
- If `timeZone` provided, kline intervals are interpreted in that timezone instead of UTC.
- Note that `startTime` and `endTime` are always interpreted in UTC, regardless of `timeZone`.
**Data Source:** Database
**Response:**
```
[ [ 1499040000000, // Kline open time "0.01634790", // Open price "0.80000000", // High price "0.01575800", // Low price "0.01577100", // Close price "148976.11427815", // Volume 1499644799999, // Kline Close time "2434.19055334", // Quote asset volume 308, // Number of trades "1756.87402397", // Taker buy base asset volume "28.46694368", // Taker buy quote asset volume "0" // Unused field, ignore. ]]
```
### UIKlines[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/uiKlines
```
The request is similar to klines having the same parameters and response.
`uiKlines` return modified kline data, optimized for presentation of candlestick charts.
**Weight:** 2
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
interval
ENUM
YES
See [`klines`](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
startTime
LONG
NO
endTime
LONG
NO
timeZone
STRING
NO
Default: 0 (UTC)
limit
INT
NO
Default: 500; Maximum: 1000.
- If `startTime` and `endTime` are not sent, the most recent klines are returned.
- Supported values for `timeZone`:
- Hours and minutes (e.g. `-1:00`, `05:45`)
- Only hours (e.g. `0`, `8`, `4`)
- Accepted range is strictly \[-12:00 to +14:00\] inclusive
- If `timeZone` provided, kline intervals are interpreted in that timezone instead of UTC.
- Note that `startTime` and `endTime` are always interpreted in UTC, regardless of `timeZone`.
**Data Source:** Database
**Response:**
```
[ [ 1499040000000, // Kline open time "0.01634790", // Open price "0.80000000", // High price "0.01575800", // Low price "0.01577100", // Close price "148976.11427815", // Volume 1499644799999, // Kline close time "2434.19055334", // Quote asset volume 308, // Number of trades "1756.87402397", // Taker buy base asset volume "28.46694368", // Taker buy quote asset volume "0" // Unused field. Ignore. ]]
```
### Current average price[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/avgPrice
```
Current average price for a symbol.
**Weight:** 2
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
**Data Source:** Memory
**Response:**
```
{ "mins": 5, // Average price interval (in minutes) "price": "9.35751834", // Average price "closeTime": 1694061154503 // Last trade time}
```
### 24hr ticker price change statistics[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/24hr
```
24 hour rolling window price change statistics. **Careful** when accessing this with no symbol.
**Weight:**
Parameter
Symbols Provided
Weight
symbol
1
2
symbol parameter is omitted
80
symbols
1-20
2
21-100
40
101 or more
80
symbols parameter is omitted
80
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
Parameter symbol and symbols cannot be used in combination.
If neither parameter is sent, tickers for all symbols will be returned in an array.
Examples of accepted format for the symbols parameter: \["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
symbols
STRING
NO
type
ENUM
NO
Supported values: FULL or MINI.
If none provided, the default is FULL
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple or all symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response - FULL:**
```
{ "symbol": "BNBBTC", "priceChange": "-94.99999800", "priceChangePercent": "-95.960", "weightedAvgPrice": "0.29628482", "prevClosePrice": "0.10002000", "lastPrice": "4.00000200", "lastQty": "200.00000000", "bidPrice": "4.00000000", "bidQty": "100.00000000", "askPrice": "4.00000200", "askQty": "100.00000000", "openPrice": "99.00000000", "highPrice": "100.00000000", "lowPrice": "0.10000000", "volume": "8913.30000000", "quoteVolume": "15.30000000", "openTime": 1499783499040, "closeTime": 1499869899040, "firstId": 28385, // First tradeId "lastId": 28460, // Last tradeId "count": 76 // Trade count}
```
OR
```
[ { "symbol": "BNBBTC", "priceChange": "-94.99999800", "priceChangePercent": "-95.960", "weightedAvgPrice": "0.29628482", "prevClosePrice": "0.10002000", "lastPrice": "4.00000200", "lastQty": "200.00000000", "bidPrice": "4.00000000", "bidQty": "100.00000000", "askPrice": "4.00000200", "askQty": "100.00000000", "openPrice": "99.00000000", "highPrice": "100.00000000", "lowPrice": "0.10000000", "volume": "8913.30000000", "quoteVolume": "15.30000000", "openTime": 1499783499040, "closeTime": 1499869899040, "firstId": 28385, // First tradeId "lastId": 28460, // Last tradeId "count": 76 // Trade count }]
```
**Response - MINI:**
```
{ "symbol": "BNBBTC", // Symbol Name "openPrice": "99.00000000", // Opening price of the Interval "highPrice": "100.00000000", // Highest price in the interval "lowPrice": "0.10000000", // Lowest price in the interval "lastPrice": "4.00000200", // Closing price of the interval "volume": "8913.30000000", // Total trade volume (in base asset) "quoteVolume": "15.30000000", // Total trade volume (in quote asset) "openTime": 1499783499040, // Start of the ticker interval "closeTime": 1499869899040, // End of the ticker interval "firstId": 28385, // First tradeId considered "lastId": 28460, // Last tradeId considered "count": 76 // Total trade count}
```
OR
```
[ { "symbol": "BNBBTC", "openPrice": "99.00000000", "highPrice": "100.00000000", "lowPrice": "0.10000000", "lastPrice": "4.00000200", "volume": "8913.30000000", "quoteVolume": "15.30000000", "openTime": 1499783499040, "closeTime": 1499869899040, "firstId": 28385, "lastId": 28460, "count": 76 }, { "symbol": "LTCBTC", "openPrice": "0.07000000", "highPrice": "0.07000000", "lowPrice": "0.07000000", "lastPrice": "0.07000000", "volume": "11.00000000", "quoteVolume": "0.77000000", "openTime": 1656908192899, "closeTime": 1656994592899, "firstId": 0, "lastId": 10, "count": 11 }]
```
### Trading Day Ticker[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/tradingDay
```
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.
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
Either symbol or symbols must be provided
Examples of accepted format for the symbols parameter:
\["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
The maximum number of symbols allowed in a request is 100.
symbols
timeZone
STRING
NO
Default: 0 (UTC)
type
ENUM
NO
Supported values: FULL or MINI.
If none provided, the default is FULL
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Notes:**
- Supported values for `timeZone`:
- Hours and minutes (e.g. `-1:00`, `05:45`)
- Only hours (e.g. `0`, `8`, `4`)
**Data Source:** Database
**Response - FULL:**
With `symbol`:
```
{ "symbol": "BTCUSDT", "priceChange": "-83.13000000", // Absolute price change "priceChangePercent": "-0.317", // Relative price change in percent "weightedAvgPrice": "26234.58803036", // quoteVolume / volume "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", // Volume in base asset "quoteVolume": "485217905.04210480", // Volume in quote asset "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, // Trade ID of the first trade in the interval "lastId": 3220849281, // Trade ID of the last trade in the interval "count": 697727 // Number of trades in the interval}
```
With `symbols`:
```
[ { "symbol": "BTCUSDT", "priceChange": "-83.13000000", "priceChangePercent": "-0.317", "weightedAvgPrice": "26234.58803036", "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", "quoteVolume": "485217905.04210480", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, "lastId": 3220849281, "count": 697727 }, { "symbol": "BNBUSDT", "priceChange": "2.60000000", "priceChangePercent": "1.238", "weightedAvgPrice": "211.92276958", "openPrice": "210.00000000", "highPrice": "213.70000000", "lowPrice": "209.70000000", "lastPrice": "212.60000000", "volume": "280709.58900000", "quoteVolume": "59488753.54750000", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 672397461, "lastId": 672496158, "count": 98698 }]
```
**Response - MINI:**
With `symbol`:
```
{ "symbol": "BTCUSDT", "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", // Volume in base asset "quoteVolume": "485217905.04210480", // Volume in quote asset "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, // Trade ID of the first trade in the interval "lastId": 3220849281, // Trade ID of the last trade in the interval "count": 697727 // Number of trades in the interval}
```
With `symbols`:
```
[ { "symbol": "BTCUSDT", "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", "quoteVolume": "485217905.04210480", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, "lastId": 3220849281, "count": 697727 }, { "symbol": "BNBUSDT", "openPrice": "210.00000000", "highPrice": "213.70000000", "lowPrice": "209.70000000", "lastPrice": "212.60000000", "volume": "280709.58900000", "quoteVolume": "59488753.54750000", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 672397461, "lastId": 672496158, "count": 98698 }]
```
### Symbol price ticker[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/price
```
Latest price for a symbol or symbols.
**Weight:**
Parameter
Symbols Provided
Weight
symbol
1
2
symbol parameter is omitted
4
symbols
Any
4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
Parameter symbol and symbols cannot be used in combination.
If neither parameter is sent, prices for all symbols will be returned in an array.
Examples of accepted format for the symbols parameter: \["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
symbols
STRING
NO
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple or all symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response:**
```
{ "symbol": "LTCBTC", "price": "4.00000200"}
```
OR
```
[ { "symbol": "LTCBTC", "price": "4.00000200" }, { "symbol": "ETHBTC", "price": "0.07946600" }]
```
### Symbol order book ticker[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/bookTicker
```
Best price/qty on the order book for a symbol or symbols.
**Weight:**
Parameter
Symbols Provided
Weight
symbol
1
2
symbol parameter is omitted
4
symbols
Any
4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
Parameter symbol and symbols cannot be used in combination.
If neither parameter is sent, bookTickers for all symbols will be returned in an array.
Examples of accepted format for the symbols parameter: \["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
symbols
STRING
NO
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple or all symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response:**
```
{ "symbol": "LTCBTC", "bidPrice": "4.00000000", "bidQty": "431.00000000", "askPrice": "4.00000200", "askQty": "9.00000000"}
```
OR
```
[ { "symbol": "LTCBTC", "bidPrice": "4.00000000", "bidQty": "431.00000000", "askPrice": "4.00000200", "askQty": "9.00000000" }, { "symbol": "ETHBTC", "bidPrice": "0.07946700", "bidQty": "9.00000000", "askPrice": "100000.00000000", "askQty": "1000.00000000" }]
```
### Rolling window price change statistics[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
```
GET /api/v3/ticker
```
**Note:** This endpoint is different from the `GET /api/v3/ticker/24hr` endpoint.
The window used to compute statistics will be no more than 59999ms from the requested `windowSize`.
`openTime` for `/api/v3/ticker` always starts on a minute, while the `closeTime` is the current time of the request. As such, the effective window will be up to 59999ms wider than `windowSize`.
E.g. If the `closeTime` is 1641287867099 (January 04, 2022 09:17:47:099 UTC) , and the `windowSize` is `1d`. the `openTime` will be: 1641201420000 (January 3, 2022, 09:17:00)
**Weight:**
4 for each requested symbol regardless of windowSize.
The weight for this request will cap at 200 once the number of `symbols` in the request is more than 50.
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
Either symbol or symbols must be provided
Examples of accepted format for the symbols parameter:
\["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
The maximum number of symbols allowed in a request is 100.
symbols
windowSize
ENUM
NO
Defaults to 1d if no parameter provided
Supported windowSize values:
1m,2m....59m for minutes
1h, 2h....23h - for hours
1d...7d - for days
Units cannot be combined (e.g. 1d2h is not allowed)
type
ENUM
NO
Supported values: FULL or MINI.
If none provided, the default is FULL
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Database
**Response - FULL:**
When using `symbol`:
```
{ "symbol": "BNBBTC", "priceChange": "-8.00000000", // Absolute price change "priceChangePercent": "-88.889", // Relative price change in percent "weightedAvgPrice": "2.60427807", // QuoteVolume / Volume "openPrice": "9.00000000", "highPrice": "9.00000000", "lowPrice": "1.00000000", "lastPrice": "1.00000000", "volume": "187.00000000", "quoteVolume": "487.00000000", // Sum of (price * volume) for all trades "openTime": 1641859200000, // Open time for ticker window "closeTime": 1642031999999, // Close time for ticker window "firstId": 0, // Trade IDs "lastId": 60, "count": 61 // Number of trades in the interval}
```
or
When using `symbols`:
```
[ { "symbol": "BTCUSDT", "priceChange": "-154.13000000", // Absolute price change "priceChangePercent": "-0.740", // Relative price change in percent "weightedAvgPrice": "20677.46305250", // QuoteVolume / Volume "openPrice": "20825.27000000", "highPrice": "20972.46000000", "lowPrice": "20327.92000000", "lastPrice": "20671.14000000", "volume": "72.65112300", "quoteVolume": "1502240.91155513", // Sum of (price * volume) for all trades "openTime": 1655432400000, // Open time for ticker window "closeTime": 1655446835460, // Close time for ticker window "firstId": 11147809, // Trade IDs "lastId": 11149775, "count": 1967 // Number of trades in the interval }, { "symbol": "BNBBTC", "priceChange": "0.00008530", "priceChangePercent": "0.823", "weightedAvgPrice": "0.01043129", "openPrice": "0.01036170", "highPrice": "0.01049850", "lowPrice": "0.01033870", "lastPrice": "0.01044700", "volume": "166.67000000", "quoteVolume": "1.73858301", "openTime": 1655432400000, "closeTime": 1655446835460, "firstId": 2351674, "lastId": 2352034, "count": 361 }]
```
**Response - MINI:**
When using `symbol`:
```
{ "symbol": "LTCBTC", "openPrice": "0.10000000", "highPrice": "2.00000000", "lowPrice": "0.10000000", "lastPrice": "2.00000000", "volume": "39.00000000", "quoteVolume": "13.40000000", // Sum of (price * volume) for all trades "openTime": 1656986580000, // Open time for ticker window "closeTime": 1657001016795, // Close time for ticker window "firstId": 0, // Trade IDs "lastId": 34, "count": 35 // Number of trades in the interval}
```
OR
When using `symbols`:
```
[ { "symbol": "BNBBTC", "openPrice": "0.10000000", "highPrice": "2.00000000", "lowPrice": "0.10000000", "lastPrice": "2.00000000", "volume": "39.00000000", "quoteVolume": "13.40000000", // Sum of (price * volume) for all trades "openTime": 1656986880000, // Open time for ticker window "closeTime": 1657001297799, // Close time for ticker window "firstId": 0, // Trade IDs "lastId": 34, "count": 35 // Number of trades in the interval }, { "symbol": "LTCBTC", "openPrice": "0.07000000", "highPrice": "0.07000000", "lowPrice": "0.07000000", "lastPrice": "0.07000000", "volume": "33.00000000", "quoteVolume": "2.31000000", "openTime": 1656986880000, "closeTime": 1657001297799, "firstId": 0, "lastId": 32, "count": 33 }]
```
- [Order book](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Recent trades list](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Old trade lookup](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Compressed/Aggregate trades list](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Kline/Candlestick data](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [UIKlines](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Current average price](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [24hr ticker price change statistics](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Trading Day Ticker](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Symbol price ticker](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Symbol order book ticker](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Rolling window price change statistics](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
@@ -1,600 +0,0 @@
---
title: "Request Security | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security"
fetched_at: "2026-02-26T10:38:09.213Z"
---
- Each endpoint has a security type indicating required API key permissions, shown next to the endpoint name (e.g., [New order (TRADE)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)).
- If unspecified, the security type is `NONE`.
- Except for `NONE`, all endpoints with a security type are considered `SIGNED` requests (i.e. including a `signature`), except for [listenKey management](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security).
- Secure endpoints require a valid API key to be specified and authenticated.
- API keys can be created on the [API Management](https://www.binance.com/en/support/faq/360002502072) page of your Binance account.
- **Both API key and secret key are sensitive.** Never share them with anyone. If you notice unusual activity in your account, immediately revoke all the keys and contact Binance support.
- API keys can be configured to allow access only to certain types of secure endpoints.
- For example, you can have an API key with `TRADE` permission for trading, while using a separate API key with `USER_DATA` permission to monitor your order status.
- By default, an API key cannot `TRADE`. You need to enable trading in API Management first.
Security type
Description
`NONE`
Public market data
`TRADE`
Trading on the exchange, placing and canceling orders
`USER_DATA`
Private account information, such as order status and your trading history
`USER_STREAM`
Managing User Data Stream subscriptions
### SIGNED Endpoint security[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
- `SIGNED` endpoints require an additional parameter, `signature`, to be sent in the `query string` or `request body`.
#### Signature Case Sensitivity[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
- **HMAC:** Signatures generated using HMAC are **not case-sensitive**. This means the signature string can be verified regardless of letter casing.
- **RSA:** Signatures generated using RSA are **case-sensitive**.
- **Ed25519:** Signatures generated using Ed25519 are also **case-sensitive**
Please consult [SIGNED request example (HMAC)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security), [SIGNED request example (RSA)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security), and [SIGNED request example (Ed25519)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security) on how to compute signature, depending on which API key type you are using.
### Timing security[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
- `SIGNED` requests also require a `timestamp` parameter which should be the current timestamp either in milliseconds or microseconds. (See [General API Information](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security))
- An additional optional parameter, `recvWindow`, specifies for how long the request stays valid and may only be specified in milliseconds.
- `recvWindow` supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
- If `recvWindow` is not sent, **it defaults to 5000 milliseconds**.
- Maximum `recvWindow` is 60000 milliseconds.
- Request processing logic is as follows:
```
serverTime = getCurrentTime()if (timestamp < (serverTime + 1 second) && (serverTime - timestamp) <= recvWindow) { // begin processing request serverTime = getCurrentTime() if (serverTime - timestamp) <= recvWindow { // forward request to Matching Engine } else { // reject request } // finish processing 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 /api/v3/order[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
#### HMAC Keys[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
The signature payload of your request is the query string concatenated without separator to the HTTP body. Any non-ASCII character must be percent-encoded before signing.
Here is a step-by-step example of how to send a valid signed payload from the Linux command line using `echo`, `openssl`, and `curl`. There is one example with a symbol name comprised entirely of ASCII characters and one example with a symbol name containing non-ASCII characters.
Example API key and secret key:
Key
Value
`apiKey`
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
`secretKey`
NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j
**WARNING: DO NOT SHARE YOUR API KEY AND SECRET KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
Parameter
Value
`symbol`
LTCBTC
`side`
BUY
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.1
`recvWindow`
5000
`timestamp`
1499827319559
Example of a request with a symbol name containing non-ASCII characters:
Parameter
Value
`symbol`
123456
`side`
BUY
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.1
`recvWindow`
5000
`timestamp`
1499827319559
**Step 1: Construct the signature payload**
1. Format parameters as `parameter=value` pairs separated by `&`.
2. Percent-encode the string.
For the first set of example parameters (ASCII only), the `parameter=value` string should look like this:
```
symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
After percent-encoding, the signature payload should look like this:
```
symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
For the second set of example parameters (some non-ASCII characters), the `parameter=value` string should look like this:
```
symbol=123456&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
After percent-encoding, the signature payload should look like this:
```
symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
**Step 2: Compute the signature**
1. Use the `secretKey` of your API key as the signing key for the HMAC-SHA-256 algorithm.
2. Sign the signature payload constructed in Step 1.
3. Encode the HMAC-SHA-256 output as a hex string.
Note that `secretKey` and the payload are **case-sensitive**, while the resulting signature value is case-insensitive.
**Example commands**
For the first set of example parameters (ASCII only):
```
$ echo -n "symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n "symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"e1353ec6b14d888f1164ae9af8228a3dbd508bc82eb867db8ab6046442f33ef3
```
**Step 3: Add signature to the request**
Complete the request by adding the `signature` parameter to the query string.
For the first set of example parameters (ASCII only):
```
curl -s -v -H "X-MBX-APIKEY: $apiKey" -X POST "https://api.binance.com/api/v3/order?symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559&signature=c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71"
```
For the second set of example parameters (some non-ASCII characters)
```
curl -s -v -H "X-MBX-APIKEY: $apiKey" -X POST "https://api.binance.com/api/v3/order?symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559&signature=e1353ec6b14d888f1164ae9af8228a3dbd508bc82eb867db8ab6046442f33ef3"
```
Here is a sample Bash script performing all the steps above:
```
apiKey="vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A"secretKey="NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"payload="symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559"# Sign the requestsignature=$(echo -n "$payload" | openssl dgst -sha256 -hmac "$secretKey")signature=${signature#*= } # Keep only the part after the "= "# Send the requestcurl -H "X-MBX-APIKEY: $apiKey" -X POST "https://api.binance.com/api/v3/order?$payload&signature=$signature"
```
#### RSA Keys[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
The signature payload of your request is the query string concatenated without separator to the HTTP body. Any non-ASCII character must be percent-encoded before signing.
To get your API key, you need to upload your RSA Public Key to your account and a corresponding API key will be provided for you.
Only `PKCS#8` keys are supported.
There is one example with a symbol name comprised entirely of ASCII characters and one example with a symbol name containing non-ASCII characters.
These examples assume the private key is stored in the file `./test-prv-key.pem`.
Key
Value
`apiKey`
CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ
Example of request with a symbol name comprised entirely of ASCII characters:
Parameter
Value
`symbol`
BTCUSDT
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
Example of a request with a symbol name containing non-ASCII characters:
Parameter
Value
`symbol`
123456
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
**Step 1: Construct the signature payload**
1. Format parameters as `parameter=value` pairs separated by `&`.
2. Percent-encode the string.
For the first set of example parameters (ASCII only), the `parameter=value` string should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
For the second set of example parameters (some non-ASCII characters), the `parameter=value` string should look like this:
```
symbol=123456=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
**Step 2: Compute the signature**
1. Sign the signature payload constructed in Step 1 using the RSASSA-PKCS1-v1\_5 algorithm with SHA-256 hash function.
2. Encode the output in base64.
Note that the payload and the resulting `signature` are **case-sensitive**.
For the first set of example parameters (ASCII only):
```
$ echo -n 'symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000' | openssl dgst -sha256 -sign ./test-prv-key.pem | openssl enc -base64 -A | tr -d '\n'HZ8HOjiJ1s/igS9JA+n7+7Ti/ihtkRF5BIWcPIEluJP6tlbFM/Bf44LfZka/iemtahZAZzcO9TnI5uaXh3++lrqtNonCwp6/245UFWkiW1elpgtVAmJPbogcAv6rSlokztAfWk296ZJXzRDYAtzGH0gq7CgSJKfH+XxaCmR0WcvlKjNQnp12/eKXJYO4tDap8UCBLuyxDnR7oJKLHQHJLP0r0EAVOOSIbrFang/1WOq+Jaq4Efc4XpnTgnwlBbWTmhWDR1pvS9iVEzcSYLHT/fNnMRxFc7u+j3qI//5yuGuu14KR0MuQKKCSpViieD+fIti46sxPTsjSemoUKp0oXA==
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n 'symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000' | openssl dgst -sha256 -sign ./test-prv-key.pem | openssl enc -base64 -A | tr -d '\n'qJtv66wyp/1mZE+mIFAAMUoTe8xkmLN7/eAZjuC9x1ocxovItHLl/sNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M+JNIMz5UFxfeA53rXjFlvsyH1Sig+OuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C/QMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt/GuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng==
```
3. Percent-encode the base64 string.
For the first set of example parameters (ASCII only):
```
HZ8HOjiJ1s%2FigS9JA%2Bn7%2B7Ti%2FihtkRF5BIWcPIEluJP6tlbFM%2FBf44LfZka%2FiemtahZAZzcO9TnI5uaXh3%2B%2BlrqtNonCwp6%2F245UFWkiW1elpgtVAmJPbogcAv6rSlokztAfWk296ZJXzRDYAtzGH0gq7CgSJKfH%2BXxaCmR0WcvlKjNQnp12%2FeKXJYO4tDap8UCBLuyxDnR7oJKLHQHJLP0r0EAVOOSIbrFang%2F1WOq%2BJaq4Efc4XpnTgnwlBbWTmhWDR1pvS9iVEzcSYLHT%2FfNnMRxFc7u%2Bj3qI%2F%2F5yuGuu14KR0MuQKKCSpViieD%2BfIti46sxPTsjSemoUKp0oXA%3D%3D
```
For the second set of example parameters (some non-ASCII characters):
```
qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D
```
**Step 3: Add signature to the request**
Complete the request by adding the `signature` parameter to the query string.
For the first set of example parameters (ASCII only):
```
curl -H "X-MBX-APIKEY: CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ" -X POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=HZ8HOjiJ1s%2FigS9JA%2Bn7%2B7Ti%2FihtkRF5BIWcPIEluJP6tlbFM%2FBf44LfZka%2FiemtahZAZzcO9TnI5uaXh3%2B%2BlrqtNonCwp6%2F245UFWkiW1elpgtVAmJPbogcAv6rSlokztAfWk296ZJXzRDYAtzGH0gq7CgSJKfH%2BXxaCmR0WcvlKjNQnp12%2FeKXJYO4tDap8UCBLuyxDnR7oJKLHQHJLP0r0EAVOOSIbrFang%2F1WOq%2BJaq4Efc4XpnTgnwlBbWTmhWDR1pvS9iVEzcSYLHT%2FfNnMRxFc7u%2Bj3qI%2F%2F5yuGuu14KR0MuQKKCSpViieD%2BfIti46sxPTsjSemoUKp0oXA%3D%3D'
```
For the second set of example parameters (some non-ASCII characters):
```
curl -H "X-MBX-APIKEY: CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ" -X POST 'https://api.binance.com/api/v3/order?symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D'
```
Here is a sample Bash script performing all the steps above:
```
function rawurlencode { local string="${1}" local strlen=${#string} local encoded="" local pos c o for (( pos=0 ; pos<strlen ; pos++ )); do c=${string:$pos:1} case "$c" in [-_.~a-zA-Z0-9] ) o="${c}" ;; * ) printf -v o '%%%02x' "'$c" esac encoded+="${o}" done echo "${encoded}"}API_KEY="put your own API Key here"PRIVATE_KEY_PATH="test-prv-key.pem"# Set up the request:API_METHOD="POST"API_CALL="api/v3/order"API_PARAMS="symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2"# Sign the request:timestamp=$(date +%s000)api_params_with_timestamp="$API_PARAMS&timestamp=$timestamp"rawSignature=$(echo -n $api_params_with_timestamp | openssl dgst -keyform PEM -sha256 -sign $PRIVATE_KEY_PATH | openssl enc -base64 | tr -d '\n')# Percent-encode the signaturesignature=$(rawurlencode "$rawSignature")# Send the request:curl -H "X-MBX-APIKEY: $API_KEY" -X "$API_METHOD" \ "https://api.binance.com/$API_CALL?$api_params_with_timestamp" \ --data-urlencode "signature=$signature"
```
#### Ed25519 Keys[](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
**Note: It is highly recommended to use Ed25519 API keys as it should provide the best performance and security out of all supported key types.**
The signature payload of your request is the query string concatenated without separator to the HTTP body. Any non-ASCII character must be percent-encoded before signing.
There is one example with a symbol name comprised entirely of ASCII characters and one example with a symbol name containing non-ASCII characters.
These examples assume the private key is stored in the file `./test-prv-key.pem`.
Key
Value
`apiKey`
4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO
Example of request with a symbol name comprised entirely of ASCII characters.
Parameter
Value
`symbol`
BTCUSDT
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
Example of a request with a symbol name containing non-ASCII characters.
Parameter
Value
`symbol`
123456
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
**Step 1: Construct the signature payload**
1. Format parameters as `parameter=value` pairs separated by `&`.
2. Percent-encode the string.
For the first set of example parameters (ASCII only), the `parameter=value` string should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
For the second set of example parameters (some non-ASCII characters), the `parameter=value` string should look like this:
```
symbol=123456&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
**Step 2: Compute the signature**
1. Sign the payload.
2. Encode the output as a base64 string.
Note that the payload and the resulting `signature` are **case-sensitive**.
For the first set of example parameters (ASCII only):
```
echo -n "symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000" | openssl dgst -keyform PEM -sha256 -sign ./test-prv-key.pem | openssl enc -base64 | tr -d '\n'HaZnek7KOGa/k5+f6Q1nw8lzMUpo36mRVvvLHCMUCXxlmdQQGZge1luAUKnleD/DYeD19YrqzeHbb6xU3MkSIXKhAO1MaYq48uGVYb3vJScEZVOutgMInrZzUcCWNulNkfcbmExSiymCZ5xQBw5QDuzpuDFqRZ1Xt+BZxEHBN9OYQKpoe0+ovjnXyVOaH8VUKhE/ghUWnThrXJr+hmSc5t7ggjiVPQc7pGn3qSNGCQwdpkQC9GHMr/r+8n6qeEKMYB5j/1wC4d8Jae8FQiU8xcXR0NlUgV2LAw61/ZJv5BTJpa+z5Lv1W9v6jHQWRX2O8uaG3KU/lR3spR7+oGlWOw=
```
For the second set of example parameters (some non-ASCII characters):
```
echo -n "symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000" | openssl dgst -keyform PEM -sha256 -sign ./test-prv-key.pem | openssl enc -base64 | tr -d '\n'qJtv66wyp/1mZE+mIFAAMUoTe8xkmLN7/eAZjuC9x1ocxovItHLl/sNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M+JNIMz5UFxfeA53rXjFlvsyH1Sig+OuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C/QMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt/GuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng==
```
3. Percent-encode the base64 string.
For the first set of example parameters (ASCII only):
```
HaZnek7KOGa%2Fk5%2Bf6Q1nw8lzMUpo36mRVvvLHCMUCXxlmdQQGZge1luAUKnleD%2FDYeD19YrqzeHbb6xU3MkSIXKhAO1MaYq48uGVYb3vJScEZVOutgMInrZzUcCWNulNkfcbmExSiymCZ5xQBw5QDuzpuDFqRZ1Xt%2BBZxEHBN9OYQKpoe0%2BovjnXyVOaH8VUKhE%2FghUWnThrXJr%2BhmSc5t7ggjiVPQc7pGn3qSNGCQwdpkQC9GHMr%2Fr%2B8n6qeEKMYB5j%2F1wC4d8Jae8FQiU8xcXR0NlUgV2LAw61%2FZJv5BTJpa%2Bz5Lv1W9v6jHQWRX2O8uaG3KU%2FlR3spR7%2BoGlWOw%3D
```
For the second set of example parameters (some non-ASCII characters):
```
qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D
```
**Step 3: Add signature to the request**
Complete the request by adding the `signature` parameter to the query string.
For the first set of example parameters (ASCII only):
```
curl -H "X-MBX-APIKEY: 4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO" -X POST 'https://api.binance.com/api/v3/order?symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=HaZnek7KOGa%2Fk5%2Bf6Q1nw8lzMUpo36mRVvvLHCMUCXxlmdQQGZge1luAUKnleD%2FDYeD19YrqzeHbb6xU3MkSIXKhAO1MaYq48uGVYb3vJScEZVOutgMInrZzUcCWNulNkfcbmExSiymCZ5xQBw5QDuzpuDFqRZ1Xt%2BBZxEHBN9OYQKpoe0%2BovjnXyVOaH8VUKhE%2FghUWnThrXJr%2BhmSc5t7ggjiVPQc7pGn3qSNGCQwdpkQC9GHMr%2Fr%2B8n6qeEKMYB5j%2F1wC4d8Jae8FQiU8xcXR0NlUgV2LAw61%2FZJv5BTJpa%2Bz5Lv1W9v6jHQWRX2O8uaG3KU%2FlR3spR7%2BoGlWOw%3D'
```
For the second set of example parameters (some non-ASCII characters):
```
curl -H "X-MBX-APIKEY: 4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO" -X POST 'https://api.binance.com/api/v3/order?symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D'
```
Here is a sample Python script performing all the steps above:
```
#!/usr/bin/env python3import base64import requestsimport timeimport urllib.parsefrom cryptography.hazmat.primitives.serialization import load_pem_private_key# Set up authenticationAPI_KEY='put your own API Key here'PRIVATE_KEY_PATH='test-prv-key.pem'# Load the private key.# In this example the key is expected to be stored without encryption,# but we recommend using a strong password for improved security.with open(PRIVATE_KEY_PATH, 'rb') as f: private_key = load_pem_private_key(data=f.read(), password=None)# Set up the request parametersparams = { 'symbol': 'BTCUSDT', 'side': 'SELL', 'type': 'LIMIT', 'timeInForce': 'GTC', 'quantity': '1.0000000', 'price': '0.20',}# Timestamp the requesttimestamp = int(time.time() * 1000) # UNIX timestamp in millisecondsparams['timestamp'] = timestamp# Sign the requestpayload = urllib.parse.urlencode(params, encoding='UTF-8')signature = base64.b64encode(private_key.sign(payload.encode('ASCII')))params['signature'] = signature# Send the requestheaders = { 'X-MBX-APIKEY': API_KEY,}response = requests.post( 'https://api.binance.com/api/v3/order', headers=headers, data=params,)print(response.json())
```
- [SIGNED Endpoint security](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
- [Timing security](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
- [SIGNED Endpoint Examples for POST /api/v3/order](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/request-security)
File diff suppressed because it is too large Load Diff
@@ -1,100 +0,0 @@
---
title: "SBE Market Data | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams"
fetched_at: "2026-02-26T10:38:09.225Z"
---
# SBE Market Data Streams
## General Information[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- The base endpoint is **stream-sbe.binance.com** or **stream-sbe.binance.com:9443**.
- To retrieve market data in JSON format, please refer to [this page](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams).
- SBE schema used for decoding the streams can be found [here](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/stream_1_0.xml).
- All symbols in stream names are **lowercase**.
- You can subscribe to a single stream at **/ws/<streamName>**.
- You can subscribe to multiple streams at **/stream?streams=<streamName1>/<streamName2>/<streamName3>**.
- A single connection to **stream-sbe.binance.com** is **only valid for 24 hours**; expect to be disconnected at the 24 hour mark.
- All time and timestamp fields are in **microseconds**.
- **An API Key is necessary for access**.
- Only Ed25519 keys are allowed.
- Please put your API Key in the `X-MBX-APIKEY` header when opening the connection. Timestamp and signature are not necessary.
- No extra API key permissions are necessary to access public market data. Symbol whitelist also does not affect access to SBE Market Data Streams.
- However, if you use an IP whitelist for the API key, only specified IP addresses are allowed to use the API key.
- The server sends a `ping frame` every 20 seconds.
- If the server does not receive a `pong frame` back from you within a minute, the connection will be closed.
- When you receive a ping, you must send a pong with a copy of ping's payload as soon as possible.
- Unsolicited `pong frames` are allowed, but will not prevent disconnection. **It is recommended that the payload for these pong frames are empty.**
- [Live Subscribing and Unsubscribing](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams) is also supported.
- You must send the subscription requests in JSON, and will receive the subscription response also in JSON.
- You can differentiate subscription responses from market data events by looking at the WebSocket frame type: subscription responses are always sent in text frames (containing JSON), and events are always sent in binary frames (containing SBE).
- If your request contains a symbol name containing non-ASCII characters, then the stream events may contain non-ASCII characters encoded in UTF-8.
## WebSocket Limits[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- WebSocket connections have a rate limit of **5 requests per second**.
- Only messages from your client are considered:
- `PING frame`
- `PONG frame`
- `Text frame` with JSON control request
- Events pushed by the server are not rate-limited.
- Connections that go beyond the limit will be closed. Repeatedly disconnected IP addresses may be banned.
- A single connection can listen to a maximum of 1024 streams.
- There is a limit of **300 connection attempts every 5 minutes per IP address**.
## Available Streams[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
### Trades Streams[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
Raw trade information, pushed in real-time.
**SBE Message Name:** `TradesStreamEvent`
**Stream Name**: <symbol>@trade
**Update Speed**: Real time
### Best Bid/Ask Streams[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
The best bid and ask price and quantity, pushed in real-time when the order book changes.
> \[!NOTE\] Best bid/ask streams in SBE are the equivalent of bookTicker streams in JSON, except they support auto-culling, and also include the `eventTime` field.
**SBE Message Name:** `BestBidAskStreamEvent`
**Stream Name**: <symbol>@bestBidAsk
**Update Speed**: Real time
SBE best bid/ask streams use **auto-culling**: when the system is under high load, it may drop outdated events instead of queuing all events and delivering them with a delay.
For example, if a best bid/ask event is generated at time T2 when there is still an undelivered event queued at time T1 (where T1 < T2), the event for T1 is dropped, and the system will deliver only the event for T2. This is done on a per-symbol basis.
### Diff. Depth Streams[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
Incremental updates to the order book, pushed at regular intervals. Use this stream to maintain a local order book.
[How to manage a local order book.](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
**SBE Message Name:** `DepthDiffStreamEvent`
**Stream Name**: <symbol>@depth
**Update Speed:** 50ms
### Partial Book Depth Streams[](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
Snapshots of the top 20 levels of the order book, pushed at regular intervals.
**SBE Message Name:** `DepthSnapshotStreamEvent`
**Stream Name**: <symbol>@depth20
**Update Speed:** 50ms
- [General Information](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- [WebSocket Limits](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- [Available Streams](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- [Trades Streams](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- [Best Bid/Ask Streams](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- [Diff. Depth Streams](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
- [Partial Book Depth Streams](https://developers.binance.com/docs/binance-spot-api-docs/sbe-market-data-streams)
File diff suppressed because it is too large Load Diff
@@ -1,9 +0,0 @@
---
title: "Testnet Terms of Use | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/TESTNET-TERMS-OF-USE"
fetched_at: "2026-02-26T10:38:09.536Z"
---
# SPOT Testnet Terms of Use
The Binance Spot Testnet and Futures Testnet are subject to the [Testnet Terms of Use](https://www.binance.com/en/about-legal/terms-testnets).
Please read it carefully before proceeding.
-213
View File
@@ -1,213 +0,0 @@
---
title: "Enums | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums"
fetched_at: "2026-02-26T10:38:09.538Z"
---
# ENUM Definitions
This will apply for both REST API and WebSocket API.
## Symbol status (status):[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `TRADING`
- `END_OF_DAY`
- `HALT`
- `BREAK`
## Account and Symbol Permissions (permissions)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `SPOT`
## Order status (status)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
Status
Description
`NEW`
The order has been accepted by the engine.
`PENDING_NEW`
The order is in a pending phase until the working order of an order list has been fully filled.
`PARTIALLY_FILLED`
A part of the order has been filled.
`FILLED`
The order has been completed.
`CANCELED`
The order has been canceled by the user.
`PENDING_CANCEL`
Currently unused
`REJECTED`
The order was not accepted by the engine and not processed.
`EXPIRED`
The order was canceled according to the order type's rules (e.g. LIMIT FOK orders with no fill, LIMIT IOC or MARKET orders that partially fill)
or by the exchange, (e.g. orders canceled during liquidation, orders canceled during maintenance)
`EXPIRED_IN_MATCH`
The order was expired by the exchange due to STP. (e.g. an order with `EXPIRE_TAKER` will match with existing orders on the book with the same account or same `tradeGroupId`)
## Order List Status (listStatusType)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
Status
Description
`RESPONSE`
This is used when the ListStatus is responding to a failed action. (E.g. order list placement or cancellation)
`EXEC_STARTED`
The order list has been placed or there is an update to the order list status.
`UPDATED`
The clientOrderId of an order in the order list has been changed.
`ALL_DONE`
The order list has finished executing and thus is no longer active.
## Order List Order Status (listOrderStatus)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
Status
Description
`EXECUTING`
Either an order list has been placed or there is an update to the status of the list.
`ALL_DONE`
An order list has completed execution and thus no longer active.
`REJECT`
The List Status is responding to a failed action either during order placement or order canceled.
## ContingencyType[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `OCO`
- `OTO`
## AllocationType[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `SOR`
## Order types (orderTypes, type)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `LIMIT`
- `MARKET`
- `STOP_LOSS`
- `STOP_LOSS_LIMIT`
- `TAKE_PROFIT`
- `TAKE_PROFIT_LIMIT`
- `LIMIT_MAKER`
## Order Response Type (newOrderRespType)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `ACK`
- `RESULT`
- `FULL`
## Working Floor[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `EXCHANGE`
- `SOR`
## Order side (side)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- `BUY`
- `SELL`
## Time in force (timeInForce)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
This sets how long an order will be active before expiration.
Status
Description
`GTC`
Good Til Canceled
An order will be on the book unless the order is canceled.
`IOC`
Immediate Or Cancel
An order will try to fill the order as much as it can before the order expires.
`FOK`
Fill or Kill
An order will expire if the full order cannot be filled upon execution.
## Rate limiters (rateLimitType)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- REQUEST\_WEIGHT
```
{ "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000}
```
- ORDERS
```
{ "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 1, "limit": 10}
```
- RAW\_REQUESTS
```
{ "rateLimitType": "RAW_REQUESTS", "interval": "MINUTE", "intervalNum": 5, "limit": 61000}
```
## Rate limit intervals (interval)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- SECOND
- MINUTE
- DAY
## STP Modes[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
Read [Self Trade Prevention (STP) FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/stp_faq) to learn more.
- `NONE`
- `EXPIRE_MAKER`
- `EXPIRE_TAKER`
- `EXPIRE_BOTH`
- `DECREMENT`
- `TRANSFER`
- [Symbol status (status):](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Account and Symbol Permissions (permissions)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Order status (status)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Order List Status (listStatusType)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Order List Order Status (listOrderStatus)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [ContingencyType](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [AllocationType](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Order types (orderTypes, type)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Order Response Type (newOrderRespType)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Working Floor](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Order side (side)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Time in force (timeInForce)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Rate limiters (rateLimitType)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [Rate limit intervals (interval)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
- [STP Modes](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
-833
View File
@@ -1,833 +0,0 @@
---
title: "Errors | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors"
fetched_at: "2026-02-26T10:38:09.991Z"
---
# Error codes for Binance SPOT Testnet
Errors consist of two parts: an error code and a message. Codes are universal, but messages can vary. Here is the error JSON payload:
```
{ "code": -1121, "msg": "Invalid symbol."}
```
## 10xx - General Server or Network issues[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
### \-1000 UNKNOWN[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- An unknown error occurred while processing the request.
### \-1001 DISCONNECTED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Internal error; unable to process your request. Please try again.
### \-1002 UNAUTHORIZED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- You are not authorized to execute this request.
### \-1003 TOO\_MANY\_REQUESTS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Too many requests queued.
- 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.
- Way too much request weight used; IP banned until %s. Please use WebSocket Streams for live updates to avoid bans.
### \-1006 UNEXPECTED\_RESP[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- An unexpected response was received from the message bus. Execution status unknown.
### \-1007 TIMEOUT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Timeout waiting for response from backend server. Send status unknown; execution status unknown.
### \-1008 SERVER\_BUSY[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Server is currently overloaded with other requests. Please try again in a few minutes.
### \-1013 INVALID\_MESSAGE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- The request is rejected by the API. (i.e. The request didn't reach the Matching Engine.)
- Potential error messages can be found in [Filter Failures](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors) or [Failures during order placement](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors).
### \-1014 UNKNOWN\_ORDER\_COMPOSITION[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Unsupported order combination.
### \-1015 TOO\_MANY\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Too many new orders.
- Too many new orders; current limit is %s orders per %s.
### \-1016 SERVICE\_SHUTTING\_DOWN[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This service is no longer available.
### \-1020 UNSUPPORTED\_OPERATION[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This operation is not supported.
### \-1021 INVALID\_TIMESTAMP[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Timestamp for this request is outside of the recvWindow.
- Timestamp for this request was 1000ms ahead of the server's time.
### \-1022 INVALID\_SIGNATURE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Signature for this request is not valid.
### \-1033 COMP\_ID\_IN\_USE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `SenderCompId(49)` is currently in use. Concurrent use of the same SenderCompId within one account is not allowed.
### \-1034 TOO\_MANY\_CONNECTIONS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Too many concurrent connections; current limit is '%s'.
- Too many connection attempts for account; current limit is %s per '%s'.
- Too many connection attempts from IP; current limit is %s per '%s'.
### \-1035 LOGGED\_OUT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Please send [Logout`<5>`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/fix-api) message to close the session.
## 11xx - Request issues[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
### \-1100 ILLEGAL\_CHARS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Illegal characters found in a parameter.
- Illegal characters found in parameter '%s'; legal range is '%s'.
### \-1101 TOO\_MANY\_PARAMETERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Too many parameters sent for this endpoint.
- Too many parameters; expected '%s' and received '%s'.
- Duplicate values for a parameter detected.
### \-1102 MANDATORY\_PARAM\_EMPTY\_OR\_MALFORMED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A mandatory parameter was not sent, was empty/null, or malformed.
- Mandatory parameter '%s' was not sent, was empty/null, or malformed.
- Param '%s' or '%s' must be sent, but both were empty/null!
- Required tag '%s' missing.
- Field value was empty or malformed.
- '%s' contains unexpected value. Cannot be greater than %s.
### \-1103 UNKNOWN\_PARAM[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- An unknown parameter was sent.
- Undefined Tag.
### \-1104 UNREAD\_PARAMETERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Not all sent parameters were read.
- Not all sent parameters were read; read '%s' parameter(s) but was sent '%s'.
### \-1105 PARAM\_EMPTY[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A parameter was empty.
- Parameter '%s' was empty.
### \-1106 PARAM\_NOT\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A parameter was sent when not required.
- Parameter '%s' sent when not required.
- A tag '%s' was sent when not required.
### \-1108 PARAM\_OVERFLOW[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Parameter '%s' overflowed.
### \-1111 BAD\_PRECISION[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Parameter '%s' has too much precision.
### \-1112 NO\_DEPTH[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- No orders on book for symbol.
### \-1114 TIF\_NOT\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- TimeInForce parameter sent when not required.
### \-1115 INVALID\_TIF[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid timeInForce.
### \-1116 INVALID\_ORDER\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid orderType.
### \-1117 INVALID\_SIDE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid side.
### \-1118 EMPTY\_NEW\_CL\_ORD\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- New client order ID was empty.
### \-1119 EMPTY\_ORG\_CL\_ORD\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Original client order ID was empty.
### \-1120 BAD\_INTERVAL[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid interval.
### \-1121 BAD\_SYMBOL[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid symbol.
### \-1122 INVALID\_SYMBOLSTATUS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid symbolStatus.
### \-1125 INVALID\_LISTEN\_KEY[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This listenKey does not exist.
### \-1127 MORE\_THAN\_XX\_HOURS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Lookup interval is too big.
- More than %s hours between startTime and endTime.
### \-1128 OPTIONAL\_PARAMS\_BAD\_COMBO[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Combination of optional parameters invalid.
- Combination of optional fields invalid. Recommendation: '%s' and '%s' must both be sent.
- Fields \[%s\] must be sent together or omitted entirely.
- Invalid `MDEntryType (269)` combination. BID and OFFER must be requested together.
- Conflicting fields: \['%s'...\]
### \-1130 INVALID\_PARAMETER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid data sent for a parameter.
- Data sent for parameter '%s' is not valid.
### \-1134 BAD\_STRATEGY\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `strategyType` was less than 1000000.
- `TargetStrategy (847)` was less than 1000000.
### \-1135 INVALID\_JSON[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid JSON Request.
- JSON sent for parameter '%s' is not valid
### \-1139 INVALID\_TICKER\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid ticker type.
### \-1145 INVALID\_CANCEL\_RESTRICTIONS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `cancelRestrictions` has to be either `ONLY_NEW` or `ONLY_PARTIALLY_FILLED`.
### \-1151 DUPLICATE\_SYMBOLS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Symbol is present multiple times in the list.
### \-1152 INVALID\_SBE\_HEADER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid `X-MBX-SBE` header; expected `<SCHEMA_ID>:<VERSION>`.
- Invalid SBE message header.
### \-1153 UNSUPPORTED\_SCHEMA\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Unsupported SBE schema ID or version specified in the `X-MBX-SBE` header.
- Invalid SBE schema ID or version specified.
### \-1155 SBE\_DISABLED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- SBE is not enabled.
### \-1158 OCO\_ORDER\_TYPE\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Order type not supported in OCO.
- If the order type provided in the `aboveType` and/or `belowType` is not supported.
### \-1160 OCO\_ICEBERGQTY\_TIMEINFORCE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Parameter '%s' is not supported if `aboveTimeInForce`/`belowTimeInForce` is not GTC.
- If the order type for the above or below leg is `STOP_LOSS_LIMIT`, and `icebergQty` is provided for that leg, the `timeInForce` has to be `GTC` else it will throw an error.
- `TimeInForce (59)` must be `GTC (1)` when `MaxFloor (111)` is used.
### \-1161 DEPRECATED\_SCHEMA[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Unable to encode the response in SBE schema 'x'. Please use schema 'y' or higher.
### \-1165 BUY\_OCO\_LIMIT\_MUST\_BE\_BELOW[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A limit order in a buy OCO must be below.
### \-1166 SELL\_OCO\_LIMIT\_MUST\_BE\_ABOVE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A limit order in a sell OCO must be above.
### \-1168 BOTH\_OCO\_ORDERS\_CANNOT\_BE\_LIMIT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- At least one OCO order must be contingent.
### \-1169 INVALID\_TAG\_NUMBER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid tag number.
### \-1170 TAG\_NOT\_DEFINED\_IN\_MESSAGE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Tag '%s' not defined for this message type.
### \-1171 TAG\_APPEARS\_MORE\_THAN\_ONCE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Tag '%s' appears more than once.
### \-1172 TAG\_OUT\_OF\_ORDER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Tag '%s' specified out of required order.
### \-1173 GROUP\_FIELDS\_OUT\_OF\_ORDER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Repeating group '%s' fields out of order.
### \-1174 INVALID\_COMPONENT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Component '%s' is incorrectly populated on '%s' order. Recommendation: '%s'
### \-1175 RESET\_SEQ\_NUM\_SUPPORT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Continuation of sequence numbers to new session is currently unsupported. Sequence numbers must be reset for each new session.
### \-1176 ALREADY\_LOGGED\_IN[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [Logon`<A>`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/fix-api) should only be sent once.
### \-1177 GARBLED\_MESSAGE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `CheckSum(10)` contains an incorrect value.
- `BeginString (8)` is not the first tag in a message.
- `MsgType (35)` is not the third tag in a message.
- `BodyLength (9)` does not contain the correct byte count.
- Only printable ASCII characters and SOH (Start of Header) are allowed.
- Tag specified without a value.
- Invalid encodingType.
### \-1178 BAD\_SENDER\_COMPID[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `SenderCompId(49)` contains an incorrect value. The SenderCompID value should not change throughout the lifetime of a session.
### \-1179 BAD\_SEQ\_NUM[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `MsgSeqNum(34)` contains an unexpected value. Expected: '%d'.
### \-1180 EXPECTED\_LOGON[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [Logon`<A>`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/fix-api) must be the first message in the session.
### \-1181 TOO\_MANY\_MESSAGES[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Too many messages; current limit is '%d' messages per '%s'.
### \-1182 PARAMS\_BAD\_COMBO[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Conflicting fields: \[%s\]
### \-1183 NOT\_ALLOWED\_IN\_DROP\_COPY\_SESSIONS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Requested operation is not allowed in DropCopy sessions.
### \-1184 DROP\_COPY\_SESSION\_NOT\_ALLOWED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- DropCopy sessions are not supported on this server. Please reconnect to a drop copy server.
### \-1185 DROP\_COPY\_SESSION\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Only DropCopy sessions are supported on this server. Either reconnect to order entry server or send `DropCopyFlag (9406)` field.
### \-1186 NOT\_ALLOWED\_IN\_ORDER\_ENTRY\_SESSIONS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Requested operation is not allowed in order entry sessions.
### \-1187 NOT\_ALLOWED\_IN\_MARKET\_DATA\_SESSIONS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Requested operation is not allowed in market data sessions.
### \-1188 INCORRECT\_NUM\_IN\_GROUP\_COUNT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Incorrect NumInGroup count for repeating group '%s'.
### \-1189 DUPLICATE\_ENTRIES\_IN\_A\_GROUP[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Group '%s' contains duplicate entries.
### \-1190 INVALID\_REQUEST\_ID[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- `MDReqID (262)` contains a subscription request id that is already in use on this connection.
- `MDReqID (262)` contains an unsubscription request id that does not match any active subscription.
### \-1191 TOO\_MANY\_SUBSCRIPTIONS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Too many subscriptions. Connection may create up to '%s' subscriptions at a time.
- Similar subscription is already active on this connection. Symbol='%s', active subscription id: '%s'.
### \-1194 INVALID\_TIME\_UNIT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid value for time unit; expected either MICROSECOND or MILLISECOND.
### \-1196 BUY\_OCO\_STOP\_LOSS\_MUST\_BE\_ABOVE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A stop loss order in a buy OCO must be above.
### \-1197 SELL\_OCO\_STOP\_LOSS\_MUST\_BE\_BELOW[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A stop loss order in a sell OCO must be below.
### \-1198 BUY\_OCO\_TAKE\_PROFIT\_MUST\_BE\_BELOW[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A take profit order in a buy OCO must be below.
### \-1199 SELL\_OCO\_TAKE\_PROFIT\_MUST\_BE\_ABOVE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- A take profit order in a sell OCO must be above.
### \-1210 INVALID\_PEG\_PRICE\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid pegPriceType.
### \-1211 INVALID\_PEG\_OFFSET\_TYPE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid pegOffsetType.
### \-1220 SYMBOL\_DOES\_NOT\_MATCH\_STATUS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- The symbol's status does not match the requested symbolStatus.
### \-1221 INVALID\_SBE\_MESSAGE\_FIELD[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid/missing field(s) in SBE message.
### \-1222 OPO\_WORKING\_MUST\_BE\_BUY[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Working order in an OPO list must be a bid.
### \-1223 OPO\_PENDING\_MUST\_BE\_SELL[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Pending orders in an OPO list must be asks.
### \-1224 WORKING\_PARAM\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Working order must include the '{param}' tag.
### \-1225 PENDING\_PARAM\_NOT\_REQUIRED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Pending orders should not include the '%s' tag.
### \-2010 NEW\_ORDER\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- NEW\_ORDER\_REJECTED
### \-2011 CANCEL\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- CANCEL\_REJECTED
### \-2013 NO\_SUCH\_ORDER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Order does not exist.
### \-2014 BAD\_API\_KEY\_FMT[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- API-key format invalid.
### \-2015 REJECTED\_MBX\_KEY[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Invalid API-key, IP, or permissions for action.
### \-2016 NO\_TRADING\_WINDOW[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- No trading window could be found for the symbol. Try ticker/24hrs instead.
### \-2026 ORDER\_ARCHIVED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Order was canceled or expired with no executed qty over 90 days ago and has been archived.
### \-2035 SUBSCRIPTION\_ACTIVE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- User Data Stream subscription already active.
### \-2036 SUBSCRIPTION\_INACTIVE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- User Data Stream subscription not active.
### \-2039 CLIENT\_ORDER\_ID\_INVALID[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Client order ID is not correct for this order ID.
### \-2042 MAXIMUM\_SUBSCRIPTION\_IDS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- Maximum subscription ID reached for this connection.
## Messages for -1010 ERROR\_MSG\_RECEIVED, -2010 NEW\_ORDER\_REJECTED, -2011 CANCEL\_REJECTED, and -2038 ORDER\_AMEND\_REJECTED[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
This code is sent when an error has been returned by the matching engine. The following messages which will indicate the specific error:
Error message
Description
"Unknown order sent."
The order (by either `orderId`, `clOrdId`, `origClOrdId`) could not be found.
"Duplicate order sent."
The `clOrdId` is already in use.
"Market is closed."
The symbol is not trading.
"Account has insufficient balance for requested action."
Not enough funds to complete the action.
"Market orders are not supported for this symbol."
`MARKET` is not enabled on the symbol.
"Iceberg orders are not supported for this symbol."
`icebergQty` is not enabled on the symbol.
"Stop loss orders are not supported for this symbol."
`STOP_LOSS` is not enabled on the symbol.
"Stop loss limit orders are not supported for this symbol."
`STOP_LOSS_LIMIT` is not enabled on the symbol.
"Take profit orders are not supported for this symbol."
`TAKE_PROFIT` is not enabled on the symbol.
"Take profit limit orders are not supported for this symbol."
`TAKE_PROFIT_LIMIT` is not enabled on the symbol.
"Order amend is not supported for this symbol."
Order amend keep priority is not enabled on the symbol.
"Price \* QTY is zero or less."
`price` \* `quantity` is too low.
"IcebergQty exceeds QTY."
`icebergQty` must be less than the order quantity.
"This action is disabled on this account."
Contact customer support; some actions have been disabled on the account.
"This account may not place or cancel orders."
Contact customer support; the account has trading ability disabled.
"Unsupported order combination"
The `orderType`, `timeInForce`, `stopPrice`, and/or `icebergQty` combination isn't allowed.
"Order would trigger immediately."
The order's stop price is not valid when compared to the last traded price.
"Cancel order is invalid. Check origClOrdId and orderId."
No `origClOrdId` or `orderId` was sent in.
"Order would immediately match and take."
`LIMIT_MAKER` order type would immediately match and trade, and not be a pure maker order.
"The relationship of the prices for the orders is not correct."
The prices set in the `OCO` is breaking the Price restrictions.
If the `aboveType` is `LIMIT_MAKER` and the `belowType` is either a `STOP_LOSS` or `STOP_LOSS_LIMIT`:
`abovePrice` > Last Traded Price > `belowStopPrice`.
If the `aboveType` is `STOP_LOSS` or `STOP_LOSS_LIMIT`, and the `belowType` is `LIMIT_MAKER`:
`aboveStopPrice` > Last Traded Price > `belowPrice`.
"OCO orders are not supported for this symbol"
`OCO` is not enabled on the symbol.
"Quote order qty market orders are not support for this symbol."
`MARKET` orders using the parameter `quoteOrderQty` are not enabled on the symbol.
"Trailing stop orders are not supported for this symbol."
Orders using `trailingDelta` are not enabled on the symbol.
"Order cancel-replace is not supported for this symbol."
`POST /api/v3/order/cancelReplace` (REST API) or `order.cancelReplace` (WebSocket API) is not enabled on the symbol.
"This symbol is not permitted for this account."
Account and symbol do not have the same permissions. (e.g. `SPOT`, `MARGIN`, etc)
"This symbol is restricted for this account."
Account is unable to trade on that symbol. (e.g. An `ISOLATED_MARGIN` account cannot place `SPOT` orders.)
"Order was not canceled due to cancel restrictions."
Either `cancelRestrictions` was set to `ONLY_NEW` but the order status was not `NEW`
or
`cancelRestrictions` was set to `ONLY_PARTIALLY_FILLED` but the order status was not `PARTIALLY_FILLED`.
"Rest API trading is not enabled." / "WebSocket API trading is not enabled."
Order is being placed or a server that is not configured to allow access to `TRADE` endpoints.
"FIX API trading is not enabled.
Order is placed on a FIX server that is not TRADE enabled.
"Order book liquidity is less than `LOT_SIZE` filter minimum quantity."
Quote quantity market orders cannot be placed when the order book liquidity is less than minimum quantity configured for the `LOT_SIZE` filter.
"Order book liquidity is less than `MARKET_LOT_SIZE` filter minimum quantity."
Quote quantity market orders cannot be placed when the order book liquidity is less than the minimum quantity for `MARKET_LOT_SIZE` filter.
"Order book liquidity is less than symbol minimum quantity."
Quote quantity market orders cannot be placed when there are no orders on the book.
"Order amend (quantity increase) is not supported."
`newQty` must be less than the order quantity.
"The requested action would change no state; rejecting".
The request sent would not have changed the status quo.
(e.g. `newQty` cannot equal the order quantity.)
"Pegged orders are not supported for this symbol."
`pegInstructionsAllowed` has not been enabled.
"This order type may not use pegged price."
You are using parameter `pegPriceType` with an unsupported order type. (e.g. `MARKET`)
"This price peg cannot be used with this order type."
You are using `pegPriceType`\=`MARKET_PEG` for a `LIMIT_MAKER` order.
"Order book liquidity is too low for this pegged order."
The order book doesnt have the best price level to peg the price to.
OPO orders are not supported for this symbol.
Order amend (pending OPO order) is not supported.
You cannot amend the pending quantity of an OPO order
## Errors regarding placing orders via cancelReplace[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
### \-2021 Order cancel-replace partially failed[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This code is sent when either the cancellation of the order failed or the new order placement failed but not both.
### \-2022 Order cancel-replace failed.[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This code is sent when both the cancellation of the order failed and the new order placement failed.
## Filter failures[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
Error message
Description
"Filter failure: PRICE\_FILTER"
`price` is too high, too low, and/or not following the tick size rule for the symbol.
"Filter failure: PERCENT\_PRICE"
`price` is X% too high or X% too low from the average weighted price over the last Y minutes.
"Filter failure: LOT\_SIZE"
`quantity` is too high, too low, and/or not following the step size rule for the symbol.
"Filter failure: MIN\_NOTIONAL"
`price` \* `quantity` is too low to be a valid order for the symbol.
"Filter failure: NOTIONAL"
`price` \* `quantity` is not within range of the `minNotional` and `maxNotional`
"Filter failure: ICEBERG\_PARTS"
`ICEBERG` order would break into too many parts; icebergQty is too small.
"Filter failure: MARKET\_LOT\_SIZE"
`MARKET` order's `quantity` is too high, too low, and/or not following the step size rule for the symbol.
"Filter failure: MAX\_POSITION"
The account's position has reached the maximum defined limit.
This is composed of the sum of the balance of the base asset, and the sum of the quantity of all open `BUY` orders.
"Filter failure: MAX\_NUM\_ORDERS"
Account has too many open orders on the symbol.
"Filter failure: MAX\_NUM\_ALGO\_ORDERS"
Account has too many open stop loss and/or take profit orders on the symbol.
"Filter failure: MAX\_NUM\_ICEBERG\_ORDERS"
Account has too many open iceberg orders on the symbol.
"Filter failure: MAX\_NUM\_ORDER\_AMENDS"
Account has made too many amendments to a single order on the symbol.
"Filter failure: MAX\_NUM\_ORDER\_LISTS"
Account has too many open order lists on the symbol.
"Filter failure: TRAILING\_DELTA"
`trailingDelta` is not within the defined range of the filter for that order type.
"Filter failure: EXCHANGE\_MAX\_NUM\_ORDERS"
Account has too many open orders on the exchange.
"Filter failure: EXCHANGE\_MAX\_NUM\_ALGO\_ORDERS"
Account has too many open stop loss and/or take profit orders on the exchange.
"Filter failure: EXCHANGE\_MAX\_NUM\_ICEBERG\_ORDERS"
Account has too many open iceberg orders on the exchange.
"Filter failure: EXCHANGE\_MAX\_NUM\_ORDER\_LISTS"
Account has too many open order lists on the exchange.
- [10xx - General Server or Network issues](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1000 UNKNOWN](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1001 DISCONNECTED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1002 UNAUTHORIZED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1003 TOO\_MANY\_REQUESTS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1006 UNEXPECTED\_RESP](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1007 TIMEOUT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1008 SERVER\_BUSY](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1013 INVALID\_MESSAGE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1014 UNKNOWN\_ORDER\_COMPOSITION](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1015 TOO\_MANY\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1016 SERVICE\_SHUTTING\_DOWN](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1020 UNSUPPORTED\_OPERATION](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1021 INVALID\_TIMESTAMP](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1022 INVALID\_SIGNATURE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1033 COMP\_ID\_IN\_USE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1034 TOO\_MANY\_CONNECTIONS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1035 LOGGED\_OUT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [11xx - Request issues](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1100 ILLEGAL\_CHARS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1101 TOO\_MANY\_PARAMETERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1102 MANDATORY\_PARAM\_EMPTY\_OR\_MALFORMED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1103 UNKNOWN\_PARAM](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1104 UNREAD\_PARAMETERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1105 PARAM\_EMPTY](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1106 PARAM\_NOT\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1108 PARAM\_OVERFLOW](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1111 BAD\_PRECISION](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1112 NO\_DEPTH](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1114 TIF\_NOT\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1115 INVALID\_TIF](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1116 INVALID\_ORDER\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1117 INVALID\_SIDE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1118 EMPTY\_NEW\_CL\_ORD\_ID](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1119 EMPTY\_ORG\_CL\_ORD\_ID](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1120 BAD\_INTERVAL](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1121 BAD\_SYMBOL](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1122 INVALID\_SYMBOLSTATUS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1125 INVALID\_LISTEN\_KEY](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1127 MORE\_THAN\_XX\_HOURS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1128 OPTIONAL\_PARAMS\_BAD\_COMBO](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1130 INVALID\_PARAMETER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1134 BAD\_STRATEGY\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1135 INVALID\_JSON](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1139 INVALID\_TICKER\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1145 INVALID\_CANCEL\_RESTRICTIONS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1151 DUPLICATE\_SYMBOLS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1152 INVALID\_SBE\_HEADER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1153 UNSUPPORTED\_SCHEMA\_ID](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1155 SBE\_DISABLED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1158 OCO\_ORDER\_TYPE\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1160 OCO\_ICEBERGQTY\_TIMEINFORCE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1161 DEPRECATED\_SCHEMA](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1165 BUY\_OCO\_LIMIT\_MUST\_BE\_BELOW](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1166 SELL\_OCO\_LIMIT\_MUST\_BE\_ABOVE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1168 BOTH\_OCO\_ORDERS\_CANNOT\_BE\_LIMIT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1169 INVALID\_TAG\_NUMBER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1170 TAG\_NOT\_DEFINED\_IN\_MESSAGE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1171 TAG\_APPEARS\_MORE\_THAN\_ONCE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1172 TAG\_OUT\_OF\_ORDER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1173 GROUP\_FIELDS\_OUT\_OF\_ORDER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1174 INVALID\_COMPONENT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1175 RESET\_SEQ\_NUM\_SUPPORT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1176 ALREADY\_LOGGED\_IN](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1177 GARBLED\_MESSAGE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1178 BAD\_SENDER\_COMPID](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1179 BAD\_SEQ\_NUM](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1180 EXPECTED\_LOGON](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1181 TOO\_MANY\_MESSAGES](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1182 PARAMS\_BAD\_COMBO](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1183 NOT\_ALLOWED\_IN\_DROP\_COPY\_SESSIONS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1184 DROP\_COPY\_SESSION\_NOT\_ALLOWED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1185 DROP\_COPY\_SESSION\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1186 NOT\_ALLOWED\_IN\_ORDER\_ENTRY\_SESSIONS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1187 NOT\_ALLOWED\_IN\_MARKET\_DATA\_SESSIONS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1188 INCORRECT\_NUM\_IN\_GROUP\_COUNT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1189 DUPLICATE\_ENTRIES\_IN\_A\_GROUP](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1190 INVALID\_REQUEST\_ID](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1191 TOO\_MANY\_SUBSCRIPTIONS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1194 INVALID\_TIME\_UNIT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1196 BUY\_OCO\_STOP\_LOSS\_MUST\_BE\_ABOVE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1197 SELL\_OCO\_STOP\_LOSS\_MUST\_BE\_BELOW](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1198 BUY\_OCO\_TAKE\_PROFIT\_MUST\_BE\_BELOW](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1199 SELL\_OCO\_TAKE\_PROFIT\_MUST\_BE\_ABOVE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1210 INVALID\_PEG\_PRICE\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1211 INVALID\_PEG\_OFFSET\_TYPE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1220 SYMBOL\_DOES\_NOT\_MATCH\_STATUS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1221 INVALID\_SBE\_MESSAGE\_FIELD](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1222 OPO\_WORKING\_MUST\_BE\_BUY](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1223 OPO\_PENDING\_MUST\_BE\_SELL](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1224 WORKING\_PARAM\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-1225 PENDING\_PARAM\_NOT\_REQUIRED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2010 NEW\_ORDER\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2011 CANCEL\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2013 NO\_SUCH\_ORDER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2014 BAD\_API\_KEY\_FMT](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2015 REJECTED\_MBX\_KEY](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2016 NO\_TRADING\_WINDOW](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2026 ORDER\_ARCHIVED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2035 SUBSCRIPTION\_ACTIVE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2036 SUBSCRIPTION\_INACTIVE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2039 CLIENT\_ORDER\_ID\_INVALID](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2042 MAXIMUM\_SUBSCRIPTION\_IDS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [Messages for -1010 ERROR\_MSG\_RECEIVED, -2010 NEW\_ORDER\_REJECTED, -2011 CANCEL\_REJECTED, and -2038 ORDER\_AMEND\_REJECTED](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [Errors regarding placing orders via cancelReplace](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2021 Order cancel-replace partially failed](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [\-2022 Order cancel-replace failed.](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- [Filter failures](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
@@ -1,324 +0,0 @@
---
title: "Filters | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters"
fetched_at: "2026-02-26T10:38:09.944Z"
---
# Filters
Filters define trading rules on a symbol or an exchange. Filters come in three forms: `symbol filters`, `exchange filters` and `asset filters`.
## Symbol filters[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
### PRICE\_FILTER[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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` % `tickSize` == 0
**/exchangeInfo format:**
```
{ "filterType": "PRICE_FILTER", "minPrice": "0.00000100", "maxPrice": "100000.00000000", "tickSize": "0.00000100"}
```
### PERCENT\_PRICE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `PERCENT_PRICE` filter defines the valid range for the 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:**
```
{ "filterType": "PERCENT_PRICE", "multiplierUp": "1.3000", "multiplierDown": "0.7000", "avgPriceMins": 5}
```
### PERCENT\_PRICE\_BY\_SIDE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `PERCENT_PRICE_BY_SIDE` filter defines the valid range for the 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.
There is a different range depending on whether the order is placed on the `BUY` side or the `SELL` side.
Buy orders will succeed on this filter if:
- `Order price` <= `weightedAveragePrice` \* `bidMultiplierUp`
- `Order price` >= `weightedAveragePrice` \* `bidMultiplierDown`
Sell orders will succeed on this filter if:
- `Order Price` <= `weightedAveragePrice` \* `askMultiplierUp`
- `Order Price` >= `weightedAveragePrice` \* `askMultiplierDown`
**/exchangeInfo format:**
```
{ "filterType": "PERCENT_PRICE_BY_SIDE", "bidMultiplierUp": "1.2", "bidMultiplierDown": "0.2", "askMultiplierUp": "5", "askMultiplierDown": "0.8", "avgPriceMins": 1}
```
### LOT\_SIZE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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` % `stepSize` == 0
**/exchangeInfo format:**
```
{ "filterType": "LOT_SIZE", "minQty": "0.00100000", "maxQty": "100000.00000000", "stepSize": "0.00100000"}
```
### MIN\_NOTIONAL[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `MIN_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 `MIN_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:**
```
{ "filterType": "MIN_NOTIONAL", "minNotional": "0.00100000", "applyToMarket": true, "avgPriceMins": 5}
```
### NOTIONAL[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `NOTIONAL` filter defines the acceptable notional range allowed for an order on a symbol.
`applyMinToMarket` determines whether the `minNotional` will be applied to `MARKET` orders.
`applyMaxToMarket` determines whether the `maxNotional` will be applied to `MARKET` orders.
In order to pass this filter, the notional (`price * quantity`) has to pass the following conditions:
- `price * quantity` <= `maxNotional`
- `price * quantity` >= `minNotional`
For `MARKET` orders, the average price used over the last `avgPriceMins` minutes will be used for calculation.
If the `avgPriceMins` is 0, then the last price will be used.
**/exchangeInfo format:**
```
{ "filterType": "NOTIONAL", "minNotional": "10.00000000", "applyMinToMarket": false, "maxNotional": "10000.00000000", "applyMaxToMarket": false, "avgPriceMins": 5}
```
### ICEBERG\_PARTS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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:**
```
{ "filterType": "ICEBERG_PARTS", "limit": 10}
```
### MARKET\_LOT\_SIZE[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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` % `stepSize` == 0
**/exchangeInfo format:**
```
{ "filterType": "MARKET_LOT_SIZE", "minQty": "0.00100000", "maxQty": "100000.00000000", "stepSize": "0.00100000"}
```
### MAX\_NUM\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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:**
```
{ "filterType": "MAX_NUM_ORDERS", "maxNumOrders": 25}
```
### MAX\_NUM\_ALGO\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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:**
```
{ "filterType": "MAX_NUM_ALGO_ORDERS", "maxNumAlgoOrders": 5}
```
### MAX\_NUM\_ICEBERG\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
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:**
```
{ "filterType": "MAX_NUM_ICEBERG_ORDERS", "maxNumIcebergOrders": 5}
```
### MAX\_POSITION[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `MAX_POSITION` 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:
1. free balance of the base asset
2. locked balance of the base asset
3. sum of the qty of all open BUY orders
`BUY` orders will be rejected if the account's position is greater than the maximum position allowed.
If an order's `quantity` can cause the position to overflow, this will also fail the `MAX_POSITION` filter.
**/exchangeInfo format:**
```
{ "filterType": "MAX_POSITION", "maxPosition": "10.00000000"}
```
### TRAILING\_DELTA[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `TRAILING_DELTA` filter defines the minimum and maximum value for the parameter [`trailingDelta`](https://developers.binance.com/docs/binance-spot-api-docs/faqs/trailing-stop-faq).
In order for a trailing stop order to pass this filter, the following must be true:
For `STOP_LOSS BUY`, `STOP_LOSS_LIMIT_BUY`,`TAKE_PROFIT SELL` and `TAKE_PROFIT_LIMIT SELL` orders:
- `trailingDelta` >= `minTrailingAboveDelta`
- `trailingDelta` <= `maxTrailingAboveDelta`
For `STOP_LOSS SELL`, `STOP_LOSS_LIMIT SELL`, `TAKE_PROFIT BUY`, and `TAKE_PROFIT_LIMIT BUY` orders:
- `trailingDelta` >= `minTrailingBelowDelta`
- `trailingDelta` <= `maxTrailingBelowDelta`
**/exchangeInfo format:**
```
{ "filterType": "TRAILING_DELTA", "minTrailingAboveDelta": 10, "maxTrailingAboveDelta": 2000, "minTrailingBelowDelta": 10, "maxTrailingBelowDelta": 2000}
```
### MAX\_NUM\_ORDER\_AMENDS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `MAX_NUM_ORDER_AMENDS` filter defines the maximum number of times an order can be [amended](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_amend_keep_priority) on the given symbol.
If there are too many order amendments made on a single order, you will receive the `-2038` error code.
**/exchangeInfo format:**
```
{ "filterType": "MAX_NUM_ORDER_AMENDS", "maxNumOrderAmends": 10}
```
### MAX\_NUM\_ORDER\_LISTS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `MAX_NUM_ORDER_LISTS` filter defines the maximum number of open order lists an account can have on a symbol. Note that OTOCOs count as one order list.
**/exchangeInfo format:**
```
{ "filterType": "MAX_NUM_ORDER_LISTS", "maxNumOrderLists": 20}
```
## Exchange Filters[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
### EXCHANGE\_MAX\_NUM\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `EXCHANGE_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:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ORDERS", "maxNumOrders": 1000}
```
### EXCHANGE\_MAX\_NUM\_ALGO\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `EXCHANGE_MAX_NUM_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:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ALGO_ORDERS", "maxNumAlgoOrders": 200}
```
### EXCHANGE\_MAX\_NUM\_ICEBERG\_ORDERS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `EXCHANGE_MAX_NUM_ICEBERG_ORDERS` filter defines the maximum number of iceberg orders an account is allowed to have open on the exchange.
**/exchangeInfo format:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ICEBERG_ORDERS", "maxNumIcebergOrders": 10000}
```
### EXCHANGE\_MAX\_NUM\_ORDER\_LISTS[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `EXCHANGE_MAX_NUM_ORDERS` filter defines the maximum number of order lists an account is allowed to have open on the exchange. Note that OTOCOs count as one order list.
**/exchangeInfo format:**
```
{ "filterType": "EXCHANGE_MAX_NUM_ORDER_LISTS", "maxNumOrderLists": 20}
```
## Asset Filters[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
### MAX\_ASSET[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
The `MAX_ASSET` filter defines the maximum quantity of an asset that an account is allowed to transact in a single order.
- When the asset is a symbol's base asset, the limit applies to the order's quantity.
- When the asset is a symbol's quote asset, the limit applies to the order's notional value.
- For example, a MAX\_ASSET filter for USDC applies to all symbols that have USDC as either a base or quote asset, such as:
- USDCBNB
- BNBUSDC
**/myFilters format:**
```
{ "filterType": "MAX_ASSET", "asset": "USDC", "limit": "42.00000000"}
```
- [Symbol filters](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [PRICE\_FILTER](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [PERCENT\_PRICE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [PERCENT\_PRICE\_BY\_SIDE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [LOT\_SIZE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MIN\_NOTIONAL](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [NOTIONAL](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [ICEBERG\_PARTS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MARKET\_LOT\_SIZE](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_NUM\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_NUM\_ALGO\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_NUM\_ICEBERG\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_POSITION](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [TRAILING\_DELTA](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_NUM\_ORDER\_AMENDS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_NUM\_ORDER\_LISTS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [Exchange Filters](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [EXCHANGE\_MAX\_NUM\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [EXCHANGE\_MAX\_NUM\_ALGO\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [EXCHANGE\_MAX\_NUM\_ICEBERG\_ORDERS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [EXCHANGE\_MAX\_NUM\_ORDER\_LISTS](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [Asset Filters](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
- [MAX\_ASSET](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters)
File diff suppressed because it is too large Load Diff
@@ -1,235 +0,0 @@
---
title: "General Info | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info"
fetched_at: "2026-02-26T10:38:09.806Z"
---
### How can I use the Spot Test Network? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
Step 1: Log in on this [website](https://testnet.binance.vision/), and generate an API Key.
Step 2: Follow the [official documentation of the Spot API](https://developers.binance.com/docs/binance-spot-api-docs/CHANGELOG), replacing the URLs of the endpoints with the following values:
Spot API URLs
Spot Test Network URLs
- https://api.binance.com/api
- https://api-gcp.binance.com/api
- https://api1.binance.com/api
- https://api2.binance.com/api
- https://api3.binance.com/api
- https://api4.binance.com/api
- **https://testnet.binance.vision/api**
- **https://api1.testnet.binance.vision/api**
- wss://ws-api.binance.com/ws-api/v3
- wss://ws-api.binance.com:9443/ws-api/v3
- **wss://ws-api.testnet.binance.vision/ws-api/v3**
- **wss://ws-api.testnet.binance.vision:9443/ws-api/v3**
- wss://stream.binance.com/ws
- wss://stream.binance.com:9443/ws
- **wss://stream.testnet.binance.vision/stream**
- **wss://stream.testnet.binance.vision:9443/stream**
- wss://stream.binance.com/stream
- wss://stream.binance.com:9443/stream
- **wss://stream.testnet.binance.vision/stream**
- **wss://stream.testnet.binance.vision:9443/stream**
- wss://stream-sbe.binance.com/ws
- wss://stream-sbe.binance.com:9443/ws
- **wss://stream-sbe.testnet.binance.vision/ws**
- **wss://stream-sbe.testnet.binance.vision:9443/ws**
- wss://stream-sbe.binance.com/stream
- wss://stream-sbe.binance.com:9443/stream
- **wss://stream-sbe.testnet.binance.vision/stream**
- **wss://stream-sbe.testnet.binance.vision:9443/stream**
- tcp+tls://fix-oe.binance.com:9000
- **tcp+tls://fix-oe.testnet.binance.vision:9000**
- tcp+tls://fix-dc.binance.com:9000
- **tcp+tls://fix-dc.testnet.binance.vision:9000**
- tcp+tls://fix-md.binance.com:9000
- **tcp+tls://fix-md.testnet.binance.vision:9000**
---
### Can I use the `/sapi` endpoints on the Spot Test Network? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
No, only the `/api` endpoints are available on the Spot Test Network:
- [Market Data Endpoints (REST API)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/market-data-endpoints)
- [Market Data Requests (WebSocket API)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/market-data-requests)
- [Websocket Market Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Trading Endpoints (REST API)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/trading-endpoints)
- [Account Endpoints (REST API)](https://developers.binance.com/docs/binance-spot-api-docs/rest-api/account-endpoints)
- [Trading Requests (WebSocket API)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/trading-requests)
- [Account Requests (WebSocket API)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/account-requests)
- [User Data Streams](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
---
### How to get funds in/out of the Spot Test Network? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
All users registering on the Spot Test Network automatically receive a balance in many different assets. Please note that these are not real assets and can be used only on the Spot Test Network itself.
All funds on the Spot Test Network are virtual, and can not be transferred in/out of the Spot Test Network.
---
### What are the restrictions on the Spot Test Network? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
**IP Limits**, **Order Rate Limits**, **Exchange Filters** and **Symbol Filters** on the Spot Test Network are generally the same as on the Spot API.
All users are encouraged to regularly query the API to get the most up-to-date rate limits & filters, for example by doing:
curl "https://testnet.binance.vision/api/v3/exchangeInfo"
---
### All my data has disappeared! What happened? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
The Spot Test Network is periodically reset to a blank state. That includes all pending and executed orders. During that reset procedure, all users automatically receive a fresh allowance of all assets.
These resets happen approximately **once per month**, and we do not offer prior notification for them.
Starting from August 2020, API Keys are preserved during resets. Users no longer need to re-register new API Keys after a reset.
---
### What is the difference between `klines` and `uiKlines`? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
On the Spot Test Network, these 2 requests always return the same data.
---
### What are RSA API Keys? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
RSA API Keys are an alternative to the typical HMAC-SHA-256 API Keys that are used to authenticate your requests on the Spot API.
Unlike HMAC-SHA-256 API Keys where we generate the secret signing key for you, with RSA API Keys, \*you\* generate a pair of public+private RSA keys, send us the public key, and sign your requests with your private key.
---
### What type of RSA keys are supported? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
We support RSA keys of any length from 2048 bits up to 4096 bits. We recommend **2048 bits keys** as a good balance between security and signature speed.
When generating the RSA signature, use the **PKCS#1 v1.5** signature scheme. This is the default when using OpenSSL. We currently do not support the PSS signature scheme.
---
### How can I use RSA API Keys? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
Step 1: Generate the private key `test-prv-key.pem`. **Do not share this file with anyone!**
openssl genrsa -out test-prv-key.pem 2048
Step 2: Generate the public key `test-pub-key.pem` from the private key.
openssl rsa -in test-prv-key.pem -pubout -outform PEM -out test-pub-key.pem
The public key should look something like this:
```
-----BEGIN PUBLIC KEY-----bL4DUXwR3ijFSXzcecQtVFU1zVWcSQd0Meztl3DLX42l/8EALJx3LSz9YKS0PMQWMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAv9ij99RAJM4JLl8Rg47bdJXMrv84WL1OK/gid4hCnxo083LYLXUpIqMmL+O6fmXAvsvkyMyT520Cw0ZNCrUkWoCjGE4JZZGF4wOkWdF37JFWbDnE/GF5mAykKj+OMaECBlZ207KleQqgVzHjKuCbhPMuBVVD3IhjBfIc7EEM438LbtayMDx4dviPWwm127jwn8qd9H3kv5JBoDfsdYMB3k39r724CljqlAfX33GpbV2LvEkL6Da3OFk+grfN98X2pCBRz5+1N95I2cRD7o+jwtCr+65E+Gqjo4OI60F9Gq5GDcrnudnUw13a4zwlU6W+Cy8gJ4R0CcKTc4+VhYVX5wW2tzLVnDqvjIN8hjhgtmUv8hr19Wn+42ev+5sNtO5QAS6sJMJG5D+cpxCNhei1Xm+1zXliaA1fvVYRqon2MdHcedFeAjzVtX38+Xweytowydcq2V/9pUUNZIzUqX7tZr3F+Ao3QOb/CuWbUBpUcbXfGv7AI1ozP8LRByyu6O8Z1dZNdkdjWVt83maUrIJHjjc7jlZY9JbH6EyYV5TenjJaupvdlx72vA7Fcgevx87seog2JALAJqZQNT+t9/tmrTUSEp3t4aINKUC1QC0CYKECAwEAAQ==-----END PUBLIC KEY-----
```
Step 3: Register your public key on the Spot Test Network.
During registration, we will generate an API Key for you that you will have to put in the `X-MBX-APIKEY` header of your requests, exactly the same way as you would do for HMAC-SHA-256 API Keys.
Step 4: When you send a request to the Spot Test Network, sign the payload using your private key.
Here is an example Bash script to post a new order and sign the request using OpenSSL. You can adapt it to your favorite programming language:
```
#!/usr/bin/env bash# Set up authentication:API_KEY="put your own API Key here"PRIVATE_KEY_PATH="test-prv-key.pem"# Set up the request:API_METHOD="POST"API_CALL="api/v3/order"API_PARAMS="symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2"# Sign the request:timestamp=$(date +%s000)api_params_with_timestamp="$API_PARAMS&timestamp=$timestamp"signature=$(echo -n "$api_params_with_timestamp" \ | openssl dgst -sha256 -sign "$PRIVATE_KEY_PATH" \ | openssl enc -base64 -A)# Send the request:curl -H "X-MBX-APIKEY: $API_KEY" -X "$API_METHOD" \ "https://testnet.binance.vision/$API_CALL?$api_params_with_timestamp" \ --data-urlencode "signature=$signature"
```
---
### What are Ed25519 API keys? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
Ed25519 API keys are an alternative to [RSA API keys](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info), using asymmetric cryptography to authenticate your requests on the Spot API.
Like RSA API keys, Ed25519 keys are _asymmetric_: you generate a keypair, share the public key with Binance, and use your private key to sign requests.
---
### Why use Ed25519 instead of RSA API keys? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
Ed25519 digital signature scheme provides security comparable to 3072-bit RSA keys, while having much smaller signatures that are faster to compute:
API key type
Signature size
Signature operation
HMAC-SHA-256
64 bytes
0.00 ms
Ed25519
88 bytes
0.03 ms
RSA (2048-bit)
344 bytes
0.55 ms
RSA (4096-bit)
684 bytes
3.42 ms
---
### How can I use Ed25519 API keys? [](https://developers.binance.com/docs/binance-spot-api-docs/testnet/general-info)
Step 1: Generate the private key `test-prv-key.pem`. **Do not share this file with anyone!**
openssl genpkey -algorithm ed25519 -out test-prv-key.pem
Step 2: Compute the public key `test-pub-key.pem` from the private key.
openssl pkey -pubout -in test-prv-key.pem -out test-pub-key.pem
The public key should look something like this:
```
-----BEGIN PUBLIC KEY-----MCowBQYDK2VwAyEACeCSz7VJkh3Bb+NF794hLMU8fLB9Zr+/tGMdVKCC2eo=-----END PUBLIC KEY-----
```
Step 3: Register your public key on the Spot Test Network.
During registration, we will generate an API key for you. Please put it in the `X-MBX-APIKEY` header of your requests, exactly the same way as with other API key types.
Step 4: When you send a request to the Spot Test Network, sign the payload using your private key.
Here is an example in Python that posts a new order signed with Ed25519 key. You can adapt it to your favorite programming language.
```
#!/usr/bin/env python3import base64import requestsimport timefrom cryptography.hazmat.primitives.serialization import load_pem_private_key# Set up authenticationAPI_KEY='put your own API Key here'PRIVATE_KEY_PATH='test-prv-key.pem'# Load the private key.# In this example the key is expected to be stored without encryption,# but we recommend using a strong password for improved security.with open(PRIVATE_KEY_PATH, 'rb') as f: private_key = load_pem_private_key(data=f.read(), password=None)# Set up the request parametersparams = { 'symbol': 'BTCUSDT', 'side': 'SELL', 'type': 'LIMIT', 'timeInForce': 'GTC', 'quantity': '1.0000000', 'price': '0.20',}# Timestamp the requesttimestamp = int(time.time() * 1000) # UNIX timestamp in millisecondsparams['timestamp'] = timestamp# Sign the requestpayload = '&'.join([f'{param}={value}' for param, value in params.items()])signature = base64.b64encode(private_key.sign(payload.encode('ASCII')))params['signature'] = signature# Send the requestheaders = { 'X-MBX-APIKEY': API_KEY,}response = requests.post( 'https://testnet.binance.vision/api/v3/order', headers=headers, data=params,)print(response.json())
```
@@ -1,910 +0,0 @@
---
title: "Account Endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints"
fetched_at: "2026-02-26T10:38:10.082Z"
---
### Account information (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/account
```
Get current account information.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
omitZeroBalances
BOOLEAN
NO
When set to `true`, emits only the non-zero balances of an account.
Default value: `false`
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Memory => Database
**Response:**
```
{ "makerCommission": 15, "takerCommission": 15, "buyerCommission": 0, "sellerCommission": 0, "commissionRates": { "maker": "0.00150000", "taker": "0.00150000", "buyer": "0.00000000", "seller": "0.00000000" }, "canTrade": true, "canWithdraw": true, "canDeposit": true, "brokered": false, "requireSelfTradePrevention": false, "preventSor": false, "updateTime": 123456789, "accountType": "SPOT", "balances": [ { "asset": "BTC", "free": "4723846.89208129", "locked": "0.00000000" }, { "asset": "LTC", "free": "4763368.68006011", "locked": "0.00000000" } ], "permissions": ["SPOT"], "uid": 354937868}
```
### Current open orders (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/openOrders
```
Get all open orders on a symbol. **Careful** when accessing this with no symbol.
**Weight:** 6 for a single symbol; **80** when the symbol parameter is omitted
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
- If the symbol is not sent, orders for all symbols will be returned in an array.
**Data Source:** Memory => Database
**Response:**
```
[ { "symbol": "LTCBTC", "orderId": 1, "orderListId": -1, // Unless it's part of an order list, value will be -1 "clientOrderId": "myOrder1", "price": "0.1", "origQty": "1.0", "executedQty": "0.0", "cummulativeQuoteQty": "0.0", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.0", "icebergQty": "0.0", "time": 1499827319559, "updateTime": 1499827319559, "isWorking": true, "origQuoteOrderQty": "0.000000", "workingTime": 1499827319559, "selfTradePreventionMode": "NONE" }]
```
**Note:** The payload above does not show all fields that can appear. Please refer to [Conditional fields in Order Responses](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/trading-endpoints).
### All orders (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/allOrders
```
Get all account orders; active, canceled, or filled.
**Weight:** 20
**Data Source:** Database
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
NO
startTime
LONG
NO
endTime
LONG
NO
limit
INT
NO
Default 500; Maximum: 1000.
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Notes:**
- If `orderId` is set, it will get orders >= that `orderId`. Otherwise most recent orders are returned.
- For some historical orders `cummulativeQuoteQty` will be < 0, meaning the data is not available at this time.
- If `startTime` and/or `endTime` provided, `orderId` is not required.
- The time between `startTime` and `endTime` can't be longer than 24 hours.
**Response:**
```
[ { "symbol": "LTCBTC", "orderId": 1, "orderListId": -1, // Unless it's part of an order list, value will be -1 "clientOrderId": "myOrder1", "price": "0.1", "origQty": "1.0", "executedQty": "0.0", "cummulativeQuoteQty": "0.0", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "stopPrice": "0.0", "icebergQty": "0.0", "time": 1499827319559, "updateTime": 1499827319559, "isWorking": true, "origQuoteOrderQty": "0.000000", "workingTime": 1499827319559, "selfTradePreventionMode": "NONE" }]
```
**Note:** The payload above does not show all fields that can appear. Please refer to [Conditional fields in Order Responses](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/trading-endpoints).
### Query Order list (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/orderList
```
Retrieves a specific order list based on provided optional parameters.
**Weight:**
4
**Parameters**:
Name
Type
Mandatory
Description
orderListId
LONG
NO\*
Query order list by `orderListId`.
`orderListId` or `origClientOrderId` must be provided.
origClientOrderId
STRING
NO\*
Query order list by `listClientOrderId`.
`orderListId` or `origClientOrderId` must be provided.
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Database
**Response:**
```
{ "orderListId": 27, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "h2USkA5YQpaXHPIrkd96xE", "transactionTime": 1565245656253, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 4, "clientOrderId": "qD1gy3kc3Gx0rihm9Y3xwS" }, { "symbol": "LTCBTC", "orderId": 5, "clientOrderId": "ARzZ9I00CPM8i3NhmU9Ega" } ]}
```
### Query all Order lists (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/allOrderList
```
Retrieves all order lists based on provided optional parameters
Note that the time between `startTime` and `endTime` can't be longer than 24 hours.
**Weight:**
20
**Parameters:**
Name
Type
Mandatory
Description
fromId
LONG
NO
If supplied, neither `startTime` or `endTime` can be provided
startTime
LONG
NO
endTime
LONG
NO
limit
INT
NO
Default: 500; Maximum: 1000
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Database
**Response:**
```
[ { "orderListId": 29, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "amEEAXryFzFwYF1FeRpUoZ", "transactionTime": 1565245913483, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 4, "clientOrderId": "oD7aesZqjEGlZrbtRpy5zB" }, { "symbol": "LTCBTC", "orderId": 5, "clientOrderId": "Jr1h6xirOxgeJOUuYQS7V3" } ] }, { "orderListId": 28, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "hG7hFNxJV6cZy3Ze4AUT4d", "transactionTime": 1565245913407, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 2, "clientOrderId": "j6lFOfbmFMRjTYA7rRJ0LP" }, { "symbol": "LTCBTC", "orderId": 3, "clientOrderId": "z0KCjOdditiLS5ekAFtK81" } ] }]
```
### Query Open Order lists (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/openOrderList
```
**Weight**: 6
**Parameters:**
Name
Type
Mandatory
Description
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Database
**Response:**
```
[ { "orderListId": 31, "contingencyType": "OCO", "listStatusType": "EXEC_STARTED", "listOrderStatus": "EXECUTING", "listClientOrderId": "wuB13fmulKj3YjdqWEcsnp", "transactionTime": 1565246080644, "symbol": "LTCBTC", "orders": [ { "symbol": "LTCBTC", "orderId": 4, "clientOrderId": "r3EH2N76dHfLoSZWIUw1bT" }, { "symbol": "LTCBTC", "orderId": 5, "clientOrderId": "Cv1SnyPD3qhqpbjpYEHbd2" } ] }]
```
### Account trade list (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/myTrades
```
Get trades for a specific account and symbol.
**Weight:**
Condition
Weight
Without orderId
20
With orderId
5
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
NO
This can only be used in combination with `symbol`.
startTime
LONG
NO
endTime
LONG
NO
fromId
LONG
NO
TradeId to fetch from. Default gets most recent trades.
limit
INT
NO
Default: 500; Maximum: 1000.
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Notes:**
- If `fromId` is set, it will get trades >= that `fromId`. Otherwise most recent trades are returned.
- The time between `startTime` and `endTime` can't be longer than 24 hours.
- These are the supported combinations of all parameters:
- `symbol`
- `symbol` + `orderId`
- `symbol` + `startTime`
- `symbol` + `endTime`
- `symbol` + `fromId`
- `symbol` + `startTime` + `endTime`
- `symbol`\+ `orderId` + `fromId`
**Data Source:** Memory => Database
**Response:**
```
[ { "symbol": "BNBBTC", "id": 28457, "orderId": 100234, "orderListId": -1, "price": "4.00000100", "qty": "12.00000000", "quoteQty": "48.000012", "commission": "10.10000000", "commissionAsset": "BNB", "time": 1499865549590, "isBuyer": true, "isMaker": false, "isBestMatch": true }]
```
### Query Unfilled Order Count (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/rateLimit/order
```
Displays the user's unfilled order count for all intervals.
**Weight:** 40
**Parameters:**
Name
Type
Mandatory
Description
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Memory
**Response:**
```
[ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 0 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 0 }]
```
### Query Prevented Matches (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/myPreventedMatches
```
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`
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
preventedMatchId
LONG
NO
orderId
LONG
NO
fromPreventedMatchId
LONG
NO
limit
INT
NO
Default: `500`; Maximum: `1000`
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Weight:**
Case
Weight
If `symbol` is invalid
2
Querying by `preventedMatchId`
2
Querying by `orderId`
20
**Data Source:**
Database
**Response:**
```
[ { "symbol": "BTCUSDT", "preventedMatchId": 1, "takerOrderId": 5, "makerSymbol": "BTCUSDT", "makerOrderId": 3, "tradeGroupId": 1, "selfTradePreventionMode": "EXPIRE_MAKER", "price": "1.100000", "makerPreventedQuantity": "1.300000", "transactTime": 1669101687094 }]
```
### Query Allocations (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/myAllocations
```
Retrieves allocations resulting from SOR order placement.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
Yes
startTime
LONG
No
endTime
LONG
No
fromAllocationId
INT
No
limit
INT
No
Default: 500; Maximum: 1000
orderId
LONG
No
recvWindow
DECIMAL
No
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
No
Supported parameter combinations:
Parameters
Response
`symbol`
allocations from oldest to newest
`symbol` + `startTime`
oldest allocations since `startTime`
`symbol` + `endTime`
newest allocations until `endTime`
`symbol` + `startTime` + `endTime`
allocations within the time range
`symbol` + `fromAllocationId`
allocations by allocation ID
`symbol` + `orderId`
allocations related to an order starting with oldest
`symbol` + `orderId` + `fromAllocationId`
allocations related to an order by allocation ID
**Note:** The time between `startTime` and `endTime` can't be longer than 24 hours.
**Data Source:** Database
**Response:**
```
[ { "symbol": "BTCUSDT", "allocationId": 0, "allocationType": "SOR", "orderId": 1, "orderListId": -1, "price": "1.00000000", "qty": "5.00000000", "quoteQty": "5.00000000", "commission": "0.00000000", "commissionAsset": "BTC", "time": 1687506878118, "isBuyer": true, "isMaker": false, "isAllocator": false }]
```
### Query Commission Rates (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/account/commission
```
Get current account commission rates.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
**Data Source:** Database
**Response:**
```
{ "symbol": "BTCUSDT", "standardCommission": { // Commission rates on trades from the order. "maker": "0.00000010", "taker": "0.00000020", "buyer": "0.00000030", "seller": "0.00000040" }, "specialCommission": { // Special commission rates from the order. "maker": "0.01000000", "taker": "0.02000000", "buyer": "0.03000000", "seller": "0.04000000" }, "taxCommission": { // Tax commission rates for trades from the order. "maker": "0.00000112", "taker": "0.00000114", "buyer": "0.00000118", "seller": "0.00000116" }, "discount": { // Discount commission when paying in BNB "enabledForAccount": true, "enabledForSymbol": true, "discountAsset": "BNB", "discount": "0.75000000" // Standard commission is reduced by this rate when paying commission in BNB. }}
```
### Query Order Amendments (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/order/amendments
```
Queries all amendments of a single order.
**Weight**: 4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
orderId
LONG
YES
fromExecutionId
LONG
NO
limit
LONG
NO
Default:500; Maximum: 1000
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:**
Database
**Response:**
```
[ { "symbol": "BTCUSDT", "orderId": 9, "executionId": 22, "origClientOrderId": "W0fJ9fiLKHOJutovPK3oJp", "newClientOrderId": "UQ1Np3bmQ71jJzsSDW9Vpi", "origQty": "5.00000000", "newQty": "4.00000000", "time": 1741669661670 }, { "symbol": "BTCUDST", "orderId": 9, "executionId": 25, "origClientOrderId": "UQ1Np3bmQ71jJzsSDW9Vpi", "newClientOrderId": "5uS0r35ohuQyDlCzZuYXq2", "origQty": "4.00000000", "newQty": "3.00000000", "time": 1741672924895 }]
```
### Query relevant filters (USER\_DATA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
```
GET /api/v3/myFilters
```
Retrieves the list of [filters](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters) relevant to an account on a given symbol. This is the only endpoint that shows if an account has [`MAX_ASSET`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/filters) filters applied to it.
**Weight:** 40
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
recvWindow
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
timestamp
LONG
YES
**Data Source:** Memory
**Response:**
```
{ "exchangeFilters": [ { "filterType": "EXCHANGE_MAX_NUM_ORDERS", "maxNumOrders": 1000 } ], "symbolFilters": [ { "filterType": "MAX_NUM_ORDER_LISTS", "maxNumOrderLists": 20 } ], "assetFilters": [ { "filterType": "MAX_ASSET", "asset": "JPY", "limit": "1000000.00000000" } ]}
```
- [Account information (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Current open orders (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [All orders (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Order list (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query all Order lists (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Open Order lists (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Account trade list (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Unfilled Order Count (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Prevented Matches (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Allocations (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Commission Rates (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query Order Amendments (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
- [Query relevant filters (USER\_DATA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints)
@@ -1,15 +0,0 @@
---
title: "Data Sources | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/data-sources"
fetched_at: "2026-02-26T10:38:10.185Z"
---
- The API system is asynchronous, so some delay in the response is normal and expected.
- Each endpoint has a data source indicating where the data is being retrieved, and thus which endpoints have the most up-to-date response.
These are the three sources, ordered by least to most potential for delays in data updates.
- **Matching Engine** - the data is from the Matching Engine
- **Memory** - the data is from a server's local or external memory
- **Database** - the data is taken directly from a database
Some endpoints can have more than 1 data source. (e.g. Memory => Database) This means that the endpoint will check the first Data Source, and if it cannot find the value it's looking for it will check the next one.
@@ -1,14 +0,0 @@
---
title: "Error Codes | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/error-codes"
fetched_at: "2026-02-26T10:38:10.206Z"
---
- Any endpoint can return an ERROR
Sample Payload below:
```
{ "code": -1121, "msg": "Invalid symbol."}
```
- Specific error codes and messages are defined in [Errors Codes](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors).
@@ -1,22 +0,0 @@
---
title: "General API Information | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-api-information"
fetched_at: "2026-02-26T10:38:10.432Z"
---
- The base endpoint is **[https://testnet.binance.vision/api](https://testnet.binance.vision/api)**
- Responses are in JSON by default. To receive responses in SBE, refer to the [SBE FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) page.
- Data is returned in **chronological order**, unless noted otherwise.
- Without `startTime` or `endTime`, returns the most recent items up to the limit.
- With `startTime`, returns oldest items from `startTime` up to the limit.
- With `endTime`, returns most recent items up to `endTime` and the limit.
- With both, behaves like `startTime` but does not exceed `endTime`.
- All time and timestamp related fields in the JSON responses are in **milliseconds by default.** To receive the information in microseconds, please add the header `X-MBX-TIME-UNIT:MICROSECOND` or `X-MBX-TIME-UNIT:microsecond`.
- We support HMAC, RSA, and Ed25519 keys. For more information, please see [API Key types](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types).
- Timestamp parameters (e.g. `startTime`, `endTime`, `timestamp`) can be passed in milliseconds or microseconds.
- If there are enums or terms you want clarification on, please see the [SPOT Glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary) for more information.
- APIs have a timeout of 10 seconds when processing a request. If a response from the Matching Engine takes longer than this, the API responds with "Timeout waiting for response from backend server. Send status unknown; execution status unknown." [(-1007 TIMEOUT)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This does not always mean that the request failed in the Matching Engine.
- If the status of the request has not appeared in [User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream), please perform an API query for its status.
- **Please avoid SQL keywords in requests** as they may trigger a security block by a WAF (Web Application Firewall) rule. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
- If your request contains a symbol name containing non-ASCII characters, then the response may contain non-ASCII characters encoded in UTF-8.
- Some endpoints may return asset and/or symbol names containing non-ASCII characters encoded in UTF-8 even if the request did not contain non-ASCII characters.
@@ -1,138 +0,0 @@
---
title: "General endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints"
fetched_at: "2026-02-26T10:38:10.484Z"
---
### Test connectivity[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints)
```
GET /api/v3/ping
```
Test connectivity to the Rest API.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{}
```
### Check server time[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints)
```
GET /api/v3/time
```
Test connectivity to the Rest API and get the current server time.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "serverTime": 1499827319559}
```
### Exchange information[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints)
```
GET /api/v3/exchangeInfo
```
Current exchange trading rules and symbol information
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
No
Example: curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?symbol=BNBBTC](https://api.binance.com/api/v3/exchangeInfo?symbol=BNBBTC)"
symbols
ARRAY OF STRING
No
Examples: curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?symbols=%5B%22BNBBTC%22,%22BTCUSDT%22%5D](https://api.binance.com/api/v3/exchangeInfo?symbols=%5B%22BNBBTC%22,%22BTCUSDT%22%5D)"
or
curl -g -X GET '[https://api.binance.com/api/v3/exchangeInfo?symbols=\["BTCUSDT","BNBBTC](https://api.binance.com/api/v3/exchangeInfo?symbols=%5B%22BTCUSDT%22,%22BNBBTC)"\]'
permissions
ENUM
No
Examples: curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?permissions=SPOT](https://api.binance.com/api/v3/exchangeInfo?permissions=SPOT)"
or
curl -X GET "[https://api.binance.com/api/v3/exchangeInfo?permissions=%5B%22MARGIN%22%2C%22LEVERAGED%22%5D](https://api.binance.com/api/v3/exchangeInfo?permissions=%5B%22MARGIN%22%2C%22LEVERAGED%22%5D)"
or
curl -g -X GET '[https://api.binance.com/api/v3/exchangeInfo?permissions=\["MARGIN","LEVERAGED](https://api.binance.com/api/v3/exchangeInfo?permissions=%5B%22MARGIN%22,%22LEVERAGED)"\]'
showPermissionSets
BOOLEAN
No
Controls whether the content of the `permissionSets` field is populated or not. Defaults to `true`
symbolStatus
ENUM
No
Filters for symbols that have this `tradingStatus`.
Valid values: `TRADING`, `HALT`, `BREAK`
Cannot be used in combination with `symbols` or `symbol`.
**Notes:**
- If the value provided to `symbol` or `symbols` do not exist, the endpoint will throw an error saying the symbol is invalid.
- All parameters are optional.
- `permissions` can support single or multiple values (e.g. `SPOT`, `["MARGIN","LEVERAGED"]`). This cannot be used in combination with `symbol` or `symbols`.
- If `permissions` parameter not provided, all symbols that have either `SPOT`, `MARGIN`, or `LEVERAGED` permission will be exposed.
- To display symbols with any permission you need to specify them explicitly in `permissions`: (e.g. `["SPOT","MARGIN",...]`.). See [Account and Symbol Permissions](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums) for the full list.
**Examples of Symbol Permissions Interpretation from the Response:**
- `[["A","B"]]` means you may place an order if your account has either permission "A" **or** permission "B".
- `[["A"],["B"]]` means you can place an order if your account has permission "A" **and** permission "B".
- `[["A"],["B","C"]]` means you can place an order if your account has permission "A" **and** permission "B" or permission "C". (Inclusive or is applied here, not exclusive or, so your account may have both permission "B" and permission "C".)
**Data Source:** Memory
**Response:**
```
{ "timezone": "UTC", "serverTime": 1565246363776, "rateLimits": [ { // These are defined in the `ENUM definitions` section under `Rate Limiters (rateLimitType)`. // All limits are optional } ], "exchangeFilters": [ // These are the defined filters in the `Filters` section. // All filters are optional. ], "symbols": [ { "symbol": "ETHBTC", "status": "TRADING", "baseAsset": "ETH", "baseAssetPrecision": 8, "quoteAsset": "BTC", "quotePrecision": 8, // will be removed in future api versions (v4+) "quoteAssetPrecision": 8, "baseCommissionPrecision": 8, "quoteCommissionPrecision": 8, "orderTypes": [ "LIMIT", "LIMIT_MAKER", "MARKET", "STOP_LOSS", "STOP_LOSS_LIMIT", "TAKE_PROFIT", "TAKE_PROFIT_LIMIT" ], "icebergAllowed": true, "ocoAllowed": true, "otoAllowed": true, "opoAllowed": true, "quoteOrderQtyMarketAllowed": true, "allowTrailingStop": false, "cancelReplaceAllowed": false, "amendAllowed": false, "pegInstructionsAllowed": true, "isSpotTradingAllowed": true, "isMarginTradingAllowed": true, "filters": [ // These are defined in the Filters section. // All filters are optional ], "permissions": [], "permissionSets": [["SPOT", "MARGIN"]], "defaultSelfTradePreventionMode": "NONE", "allowedSelfTradePreventionModes": ["NONE"] } ], // Optional field. Present only when SOR is available. // https://github.com/binance/binance-spot-api-docs/blob/master/faqs/sor_faq.md "sors": [ { "baseAsset": "BTC", "symbols": ["BTCUSDT", "BTCUSDC"] } ]}
```
- [Test connectivity](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints)
- [Check server time](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints)
- [Exchange information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-endpoints)
@@ -1,9 +0,0 @@
---
title: "General Information on Endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/general-information-on-endpoints"
fetched_at: "2026-02-26T10:38:10.575Z"
---
- For `GET` endpoints, parameters must be sent as a `query string`.
- For `POST`, `PUT`, and `DELETE` 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 `query string` parameter will be used.
@@ -1,11 +0,0 @@
---
title: "HTTP Return Codes | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/http-return-codes"
fetched_at: "2026-02-26T10:38:10.463Z"
---
- HTTP `4XX` return codes are used for malformed requests; the issue is on the sender's side.
- HTTP `403` return code is used when a WAF (Web Application Firewall) rule has been violated. This can indicate a rate limit violation or a security block. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
- HTTP `409` return code is used when a cancelReplace order partially succeeds. (i.e. if the cancellation of the order fails but the new order placement succeeds.)
- 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 Binance's side. It is important to **NOT** treat this as a failure operation; the execution status is **UNKNOWN** and could have been a success.
@@ -1,39 +0,0 @@
---
title: "LIMITS | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/limits"
fetched_at: "2026-02-26T10:38:10.693Z"
---
### General Info on Limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/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".
- The `/api/v3/exchangeInfo` `rateLimits` array contains objects related to the exchange's `RAW_REQUESTS`, `REQUEST_WEIGHT`, and `ORDERS` rate limits. These are further defined in the `ENUM definitions` section under `Rate limiters (rateLimitType)`.
- Requests fail with HTTP status code 429 when you exceed the request rate limit.
### IP Limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/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 429, to prevent a ban, or, in the case of a 418, until the ban is over.
- **The limits on the API are based on the IPs, not the API keys.**
### Unfilled Order Count[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/limits)
- Every successful order response will contain a `X-MBX-ORDER-COUNT-(intervalNum)(intervalLetter)` header indicating how many orders you have placed for that interval.
To monitor this, refer to [`GET api/v3/rateLimit/order`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/account-endpoints).
- Rejected/unsuccessful orders are not guaranteed to have `X-MBX-ORDER-COUNT-**` headers in the response.
- If you have exceeded this, you will receive a 429 error with the `Retry-After` header.
- **Please note that if your orders are consistently filled by trades, you can continuously place orders on the API**. For more information, please see [Spot Unfilled Order Count Rules](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement).
- **The number of unfilled orders is tracked for each account.**
- [General Info on Limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/limits)
- [IP Limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/limits)
- [Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/limits)
@@ -1,981 +0,0 @@
---
title: "Market Data endpoints | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints"
fetched_at: "2026-02-26T10:38:10.755Z"
---
### Order book[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/depth
```
**Weight:** Adjusted based on the limit:
Limit
Request Weight
1-100
5
101-500
25
501-1000
50
1001-5000
250
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
limit
INT
NO
Default: 100; Maximum: 5000.
If limit > 5000, only 5000 entries will be returned.
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
A status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response:**
```
{ "lastUpdateId": 1027024, "bids": [ [ "4.00000000", // PRICE "431.00000000" // QTY ] ], "asks": [["4.00000200", "12.00000000"]]}
```
### Recent trades list[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/trades
```
Get recent trades.
**Weight:** 25
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
limit
INT
NO
Default: 500; Maximum: 1000.
**Data Source:** Memory
**Response:**
```
[ { "id": 28457, "price": "4.00000100", "qty": "12.00000000", "quoteQty": "48.000012", "time": 1499865549590, "isBuyerMaker": true, "isBestMatch": true }]
```
### Old trade lookup[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/historicalTrades
```
Get older trades.
**Weight:** 25
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
limit
INT
NO
Default: 500; Maximum: 1000.
fromId
LONG
NO
TradeId to fetch from. Default gets most recent trades.
**Data Source:** Database
**Response:**
```
[ { "id": 28457, "price": "4.00000100", "qty": "12.00000000", "quoteQty": "48.000012", "time": 1499865549590, "isBuyerMaker": true, "isBestMatch": true }]
```
### Compressed/Aggregate trades list[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/aggTrades
```
Get compressed, aggregate trades. Trades that fill at the time, from the same taker order, with the same price will have the quantity aggregated.
**Weight:** 4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
fromId
LONG
NO
ID to get aggregate trades from INCLUSIVE.
startTime
LONG
NO
Timestamp in ms to get aggregate trades from INCLUSIVE.
endTime
LONG
NO
Timestamp in ms to get aggregate trades until INCLUSIVE.
limit
INT
NO
Default: 500; Maximum: 1000.
- If fromId, startTime, and endTime are not sent, the most recent aggregate trades will be returned.
**Data Source:** Database
**Response:**
```
[ { "a": 26129, // Aggregate tradeId "p": "0.01633102", // Price "q": "4.70443515", // Quantity "f": 27781, // First tradeId "l": 27781, // Last tradeId "T": 1498793709153, // Timestamp "m": true, // Was the buyer the maker? "M": true // Was the trade the best price match? }]
```
### Kline/Candlestick data[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/klines
```
Kline/candlestick bars for a symbol. Klines are uniquely identified by their open time.
**Weight:** 2
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
interval
ENUM
YES
startTime
LONG
NO
endTime
LONG
NO
timeZone
STRING
NO
Default: 0 (UTC)
limit
INT
NO
Default: 500; Maximum: 1000.
Supported kline intervals (case-sensitive):
Interval
`interval` value
seconds
`1s`
minutes
`1m`, `3m`, `5m`, `15m`, `30m`
hours
`1h`, `2h`, `4h`, `6h`, `8h`, `12h`
days
`1d`, `3d`
weeks
`1w`
months
`1M`
**Notes:**
- If `startTime` and `endTime` are not sent, the most recent klines are returned.
- Supported values for `timeZone`:
- Hours and minutes (e.g. `-1:00`, `05:45`)
- Only hours (e.g. `0`, `8`, `4`)
- Accepted range is strictly \[-12:00 to +14:00\] inclusive
- If `timeZone` provided, kline intervals are interpreted in that timezone instead of UTC.
- Note that `startTime` and `endTime` are always interpreted in UTC, regardless of `timeZone`.
**Data Source:** Database
**Response:**
```
[ [ 1499040000000, // Kline open time "0.01634790", // Open price "0.80000000", // High price "0.01575800", // Low price "0.01577100", // Close price "148976.11427815", // Volume 1499644799999, // Kline Close time "2434.19055334", // Quote asset volume 308, // Number of trades "1756.87402397", // Taker buy base asset volume "28.46694368", // Taker buy quote asset volume "0" // Unused field, ignore. ]]
```
### UIKlines[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/uiKlines
```
The request is similar to klines having the same parameters and response.
`uiKlines` return modified kline data, optimized for presentation of candlestick charts.
**Weight:** 2
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
interval
ENUM
YES
See [`klines`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
startTime
LONG
NO
endTime
LONG
NO
timeZone
STRING
NO
Default: 0 (UTC)
limit
INT
NO
Default: 500; Maximum: 1000.
- If `startTime` and `endTime` are not sent, the most recent klines are returned.
- Supported values for `timeZone`:
- Hours and minutes (e.g. `-1:00`, `05:45`)
- Only hours (e.g. `0`, `8`, `4`)
- Accepted range is strictly \[-12:00 to +14:00\] inclusive
- If `timeZone` provided, kline intervals are interpreted in that timezone instead of UTC.
- Note that `startTime` and `endTime` are always interpreted in UTC, regardless of `timeZone`.
**Data Source:** Database
**Response:**
```
[ [ 1499040000000, // Kline open time "0.01634790", // Open price "0.80000000", // High price "0.01575800", // Low price "0.01577100", // Close price "148976.11427815", // Volume 1499644799999, // Kline close time "2434.19055334", // Quote asset volume 308, // Number of trades "1756.87402397", // Taker buy base asset volume "28.46694368", // Taker buy quote asset volume "0" // Unused field. Ignore. ]]
```
### Current average price[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/avgPrice
```
Current average price for a symbol.
**Weight:** 2
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
**Data Source:** Memory
**Response:**
```
{ "mins": 5, // Average price interval (in minutes) "price": "9.35751834", // Average price "closeTime": 1694061154503 // Last trade time}
```
### 24hr ticker price change statistics[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/24hr
```
24 hour rolling window price change statistics. **Careful** when accessing this with no symbol.
**Weight:**
Parameter
Symbols Provided
Weight
symbol
1
2
symbol parameter is omitted
80
symbols
1-20
2
21-100
40
101 or more
80
symbols parameter is omitted
80
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
Parameter symbol and symbols cannot be used in combination.
If neither parameter is sent, tickers for all symbols will be returned in an array.
Examples of accepted format for the symbols parameter: \["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
symbols
STRING
NO
type
ENUM
NO
Supported values: FULL or MINI.
If none provided, the default is FULL
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple or all symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response - FULL:**
```
{ "symbol": "BNBBTC", "priceChange": "-94.99999800", "priceChangePercent": "-95.960", "weightedAvgPrice": "0.29628482", "prevClosePrice": "0.10002000", "lastPrice": "4.00000200", "lastQty": "200.00000000", "bidPrice": "4.00000000", "bidQty": "100.00000000", "askPrice": "4.00000200", "askQty": "100.00000000", "openPrice": "99.00000000", "highPrice": "100.00000000", "lowPrice": "0.10000000", "volume": "8913.30000000", "quoteVolume": "15.30000000", "openTime": 1499783499040, "closeTime": 1499869899040, "firstId": 28385, // First tradeId "lastId": 28460, // Last tradeId "count": 76 // Trade count}
```
OR
```
[ { "symbol": "BNBBTC", "priceChange": "-94.99999800", "priceChangePercent": "-95.960", "weightedAvgPrice": "0.29628482", "prevClosePrice": "0.10002000", "lastPrice": "4.00000200", "lastQty": "200.00000000", "bidPrice": "4.00000000", "bidQty": "100.00000000", "askPrice": "4.00000200", "askQty": "100.00000000", "openPrice": "99.00000000", "highPrice": "100.00000000", "lowPrice": "0.10000000", "volume": "8913.30000000", "quoteVolume": "15.30000000", "openTime": 1499783499040, "closeTime": 1499869899040, "firstId": 28385, // First tradeId "lastId": 28460, // Last tradeId "count": 76 // Trade count }]
```
**Response - MINI:**
```
{ "symbol": "BNBBTC", // Symbol Name "openPrice": "99.00000000", // Opening price of the Interval "highPrice": "100.00000000", // Highest price in the interval "lowPrice": "0.10000000", // Lowest price in the interval "lastPrice": "4.00000200", // Closing price of the interval "volume": "8913.30000000", // Total trade volume (in base asset) "quoteVolume": "15.30000000", // Total trade volume (in quote asset) "openTime": 1499783499040, // Start of the ticker interval "closeTime": 1499869899040, // End of the ticker interval "firstId": 28385, // First tradeId considered "lastId": 28460, // Last tradeId considered "count": 76 // Total trade count}
```
OR
```
[ { "symbol": "BNBBTC", "openPrice": "99.00000000", "highPrice": "100.00000000", "lowPrice": "0.10000000", "lastPrice": "4.00000200", "volume": "8913.30000000", "quoteVolume": "15.30000000", "openTime": 1499783499040, "closeTime": 1499869899040, "firstId": 28385, "lastId": 28460, "count": 76 }, { "symbol": "LTCBTC", "openPrice": "0.07000000", "highPrice": "0.07000000", "lowPrice": "0.07000000", "lastPrice": "0.07000000", "volume": "11.00000000", "quoteVolume": "0.77000000", "openTime": 1656908192899, "closeTime": 1656994592899, "firstId": 0, "lastId": 10, "count": 11 }]
```
### Trading Day Ticker[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/tradingDay
```
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.
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
Either symbol or symbols must be provided
Examples of accepted format for the symbols parameter:
\["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
The maximum number of symbols allowed in a request is 100.
symbols
timeZone
STRING
NO
Default: 0 (UTC)
type
ENUM
NO
Supported values: FULL or MINI.
If none provided, the default is FULL
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Notes:**
- Supported values for `timeZone`:
- Hours and minutes (e.g. `-1:00`, `05:45`)
- Only hours (e.g. `0`, `8`, `4`)
**Data Source:** Database
**Response - FULL:**
With `symbol`:
```
{ "symbol": "BTCUSDT", "priceChange": "-83.13000000", // Absolute price change "priceChangePercent": "-0.317", // Relative price change in percent "weightedAvgPrice": "26234.58803036", // quoteVolume / volume "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", // Volume in base asset "quoteVolume": "485217905.04210480", // Volume in quote asset "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, // Trade ID of the first trade in the interval "lastId": 3220849281, // Trade ID of the last trade in the interval "count": 697727 // Number of trades in the interval}
```
With `symbols`:
```
[ { "symbol": "BTCUSDT", "priceChange": "-83.13000000", "priceChangePercent": "-0.317", "weightedAvgPrice": "26234.58803036", "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", "quoteVolume": "485217905.04210480", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, "lastId": 3220849281, "count": 697727 }, { "symbol": "BNBUSDT", "priceChange": "2.60000000", "priceChangePercent": "1.238", "weightedAvgPrice": "211.92276958", "openPrice": "210.00000000", "highPrice": "213.70000000", "lowPrice": "209.70000000", "lastPrice": "212.60000000", "volume": "280709.58900000", "quoteVolume": "59488753.54750000", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 672397461, "lastId": 672496158, "count": 98698 }]
```
**Response - MINI:**
With `symbol`:
```
{ "symbol": "BTCUSDT", "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", // Volume in base asset "quoteVolume": "485217905.04210480", // Volume in quote asset "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, // Trade ID of the first trade in the interval "lastId": 3220849281, // Trade ID of the last trade in the interval "count": 697727 // Number of trades in the interval}
```
With `symbols`:
```
[ { "symbol": "BTCUSDT", "openPrice": "26304.80000000", "highPrice": "26397.46000000", "lowPrice": "26088.34000000", "lastPrice": "26221.67000000", "volume": "18495.35066000", "quoteVolume": "485217905.04210480", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 3220151555, "lastId": 3220849281, "count": 697727 }, { "symbol": "BNBUSDT", "openPrice": "210.00000000", "highPrice": "213.70000000", "lowPrice": "209.70000000", "lastPrice": "212.60000000", "volume": "280709.58900000", "quoteVolume": "59488753.54750000", "openTime": 1695686400000, "closeTime": 1695772799999, "firstId": 672397461, "lastId": 672496158, "count": 98698 }]
```
### Symbol price ticker[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/price
```
Latest price for a symbol or symbols.
**Weight:**
Parameter
Symbols Provided
Weight
symbol
1
2
symbol parameter is omitted
4
symbols
Any
4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
Parameter symbol and symbols cannot be used in combination.
If neither parameter is sent, prices for all symbols will be returned in an array.
Examples of accepted format for the symbols parameter: \["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
symbols
STRING
NO
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple or all symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response:**
```
{ "symbol": "LTCBTC", "price": "4.00000200"}
```
OR
```
[ { "symbol": "LTCBTC", "price": "4.00000200" }, { "symbol": "ETHBTC", "price": "0.07946600" }]
```
### Symbol order book ticker[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/ticker/bookTicker
```
Best price/qty on the order book for a symbol or symbols.
**Weight:**
Parameter
Symbols Provided
Weight
symbol
1
2
symbol parameter is omitted
4
symbols
Any
4
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
NO
Parameter symbol and symbols cannot be used in combination.
If neither parameter is sent, bookTickers for all symbols will be returned in an array.
Examples of accepted format for the symbols parameter: \["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
symbols
STRING
NO
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple or all symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Memory
**Response:**
```
{ "symbol": "LTCBTC", "bidPrice": "4.00000000", "bidQty": "431.00000000", "askPrice": "4.00000200", "askQty": "9.00000000"}
```
OR
```
[ { "symbol": "LTCBTC", "bidPrice": "4.00000000", "bidQty": "431.00000000", "askPrice": "4.00000200", "askQty": "9.00000000" }, { "symbol": "ETHBTC", "bidPrice": "0.07946700", "bidQty": "9.00000000", "askPrice": "100000.00000000", "askQty": "1000.00000000" }]
```
### Rolling window price change statistics[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
```
GET /api/v3/ticker
```
**Note:** This endpoint is different from the `GET /api/v3/ticker/24hr` endpoint.
The window used to compute statistics will be no more than 59999ms from the requested `windowSize`.
`openTime` for `/api/v3/ticker` always starts on a minute, while the `closeTime` is the current time of the request. As such, the effective window will be up to 59999ms wider than `windowSize`.
E.g. If the `closeTime` is 1641287867099 (January 04, 2022 09:17:47:099 UTC) , and the `windowSize` is `1d`. the `openTime` will be: 1641201420000 (January 3, 2022, 09:17:00)
**Weight:**
4 for each requested symbol regardless of windowSize.
The weight for this request will cap at 200 once the number of `symbols` in the request is more than 50.
**Parameters:**
Name
Type
Mandatory
Description
symbol
STRING
YES
Either symbol or symbols must be provided
Examples of accepted format for the symbols parameter:
\["BTCUSDT","BNBUSDT"\]
or
%5B%22BTCUSDT%22,%22BNBUSDT%22%5D
The maximum number of symbols allowed in a request is 100.
symbols
windowSize
ENUM
NO
Defaults to 1d if no parameter provided
Supported windowSize values:
1m,2m....59m for minutes
1h, 2h....23h - for hours
1d...7d - for days
Units cannot be combined (e.g. 1d2h is not allowed)
type
ENUM
NO
Supported values: FULL or MINI.
If none provided, the default is FULL
symbolStatus
ENUM
NO
Filters for symbols that have this `tradingStatus`.
For a single symbol, a status mismatch returns error `-1220 SYMBOL_DOES_NOT_MATCH_STATUS`.
For multiple symbols, non-matching ones are simply excluded from the response.
Valid values: `TRADING`, `HALT`, `BREAK`
**Data Source:** Database
**Response - FULL:**
When using `symbol`:
```
{ "symbol": "BNBBTC", "priceChange": "-8.00000000", // Absolute price change "priceChangePercent": "-88.889", // Relative price change in percent "weightedAvgPrice": "2.60427807", // QuoteVolume / Volume "openPrice": "9.00000000", "highPrice": "9.00000000", "lowPrice": "1.00000000", "lastPrice": "1.00000000", "volume": "187.00000000", "quoteVolume": "487.00000000", // Sum of (price * volume) for all trades "openTime": 1641859200000, // Open time for ticker window "closeTime": 1642031999999, // Close time for ticker window "firstId": 0, // Trade IDs "lastId": 60, "count": 61 // Number of trades in the interval}
```
or
When using `symbols`:
```
[ { "symbol": "BTCUSDT", "priceChange": "-154.13000000", // Absolute price change "priceChangePercent": "-0.740", // Relative price change in percent "weightedAvgPrice": "20677.46305250", // QuoteVolume / Volume "openPrice": "20825.27000000", "highPrice": "20972.46000000", "lowPrice": "20327.92000000", "lastPrice": "20671.14000000", "volume": "72.65112300", "quoteVolume": "1502240.91155513", // Sum of (price * volume) for all trades "openTime": 1655432400000, // Open time for ticker window "closeTime": 1655446835460, // Close time for ticker window "firstId": 11147809, // Trade IDs "lastId": 11149775, "count": 1967 // Number of trades in the interval }, { "symbol": "BNBBTC", "priceChange": "0.00008530", "priceChangePercent": "0.823", "weightedAvgPrice": "0.01043129", "openPrice": "0.01036170", "highPrice": "0.01049850", "lowPrice": "0.01033870", "lastPrice": "0.01044700", "volume": "166.67000000", "quoteVolume": "1.73858301", "openTime": 1655432400000, "closeTime": 1655446835460, "firstId": 2351674, "lastId": 2352034, "count": 361 }]
```
**Response - MINI:**
When using `symbol`:
```
{ "symbol": "LTCBTC", "openPrice": "0.10000000", "highPrice": "2.00000000", "lowPrice": "0.10000000", "lastPrice": "2.00000000", "volume": "39.00000000", "quoteVolume": "13.40000000", // Sum of (price * volume) for all trades "openTime": 1656986580000, // Open time for ticker window "closeTime": 1657001016795, // Close time for ticker window "firstId": 0, // Trade IDs "lastId": 34, "count": 35 // Number of trades in the interval}
```
OR
When using `symbols`:
```
[ { "symbol": "BNBBTC", "openPrice": "0.10000000", "highPrice": "2.00000000", "lowPrice": "0.10000000", "lastPrice": "2.00000000", "volume": "39.00000000", "quoteVolume": "13.40000000", // Sum of (price * volume) for all trades "openTime": 1656986880000, // Open time for ticker window "closeTime": 1657001297799, // Close time for ticker window "firstId": 0, // Trade IDs "lastId": 34, "count": 35 // Number of trades in the interval }, { "symbol": "LTCBTC", "openPrice": "0.07000000", "highPrice": "0.07000000", "lowPrice": "0.07000000", "lastPrice": "0.07000000", "volume": "33.00000000", "quoteVolume": "2.31000000", "openTime": 1656986880000, "closeTime": 1657001297799, "firstId": 0, "lastId": 32, "count": 33 }]
```
- [Order book](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Recent trades list](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Old trade lookup](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Compressed/Aggregate trades list](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Kline/Candlestick data](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [UIKlines](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Current average price](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [24hr ticker price change statistics](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Trading Day Ticker](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Symbol price ticker](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Symbol order book ticker](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
- [Rolling window price change statistics](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/market-data-endpoints)
@@ -1,600 +0,0 @@
---
title: "Request Security | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security"
fetched_at: "2026-02-26T10:38:10.989Z"
---
- Each endpoint has a security type indicating required API key permissions, shown next to the endpoint name (e.g., [New order (TRADE)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)).
- If unspecified, the security type is `NONE`.
- Except for `NONE`, all endpoints with a security type are considered `SIGNED` requests (i.e. including a `signature`), except for [listenKey management](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security).
- Secure endpoints require a valid API key to be specified and authenticated.
- API keys can be created on the [SPOT Test Network](https://testnet.binance.vision/) upon logging in with your Github account.
- **Both API key and secret key are sensitive.** Never share them with anyone. If you notice unusual activity in your account, immediately revoke all the keys and contact Binance support.
- API keys can be configured to allow access only to certain types of secure endpoints.
- For example, you can have an API key with `TRADE` permission for trading, while using a separate API key with `USER_DATA` permission to monitor your order status.
- By default, an API key cannot `TRADE`. You need to enable trading in API Management first.
Security type
Description
`NONE`
Public market data
`TRADE`
Trading on the exchange, placing and canceling orders
`USER_DATA`
Private account information, such as order status and your trading history
`USER_STREAM`
Managing User Data Stream subscriptions
### SIGNED Endpoint security[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
- `SIGNED` endpoints require an additional parameter, `signature`, to be sent in the `query string` or `request body`.
#### Signature Case Sensitivity[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
- **HMAC:** Signatures generated using HMAC are **not case-sensitive**. This means the signature string can be verified regardless of letter casing.
- **RSA:** Signatures generated using RSA are **case-sensitive**.
- **Ed25519:** Signatures generated using Ed25519 are also **case-sensitive**
Please consult [SIGNED request example (HMAC)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security), [SIGNED request example (RSA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security), and [SIGNED request example (Ed25519)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security) on how to compute signature, depending on which API key type you are using.
### Timing security[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
- `SIGNED` requests also require a `timestamp` parameter which should be the current timestamp either in milliseconds or microseconds. (See [General API Information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security))
- An additional optional parameter, `recvWindow`, specifies for how long the request stays valid and may only be specified in milliseconds.
- `recvWindow` supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
- If `recvWindow` is not sent, **it defaults to 5000 milliseconds**.
- Maximum `recvWindow` is 60000 milliseconds.
- Request processing logic is as follows:
```
serverTime = getCurrentTime()if (timestamp < (serverTime + 1 second) && (serverTime - timestamp) <= recvWindow) { // begin processing request serverTime = getCurrentTime() if (serverTime - timestamp) <= recvWindow { // forward request to Matching Engine } else { // reject request } // finish processing 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 /api/v3/order[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
#### HMAC Keys[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
The signature payload of your request is the query string concatenated without separator to the HTTP body. Any non-ASCII character must be percent-encoded before signing.
Here is a step-by-step example of how to send a valid signed payload from the Linux command line using `echo`, `openssl`, and `curl`. There is one example with a symbol name comprised entirely of ASCII characters and one example with a symbol name containing non-ASCII characters.
Example API key and secret key:
Key
Value
`apiKey`
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
`secretKey`
NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j
**WARNING: DO NOT SHARE YOUR API KEY AND SECRET KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
Parameter
Value
`symbol`
LTCBTC
`side`
BUY
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.1
`recvWindow`
5000
`timestamp`
1499827319559
Example of a request with a symbol name containing non-ASCII characters:
Parameter
Value
`symbol`
123456
`side`
BUY
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.1
`recvWindow`
5000
`timestamp`
1499827319559
**Step 1: Construct the signature payload**
1. Format parameters as `parameter=value` pairs separated by `&`.
2. Percent-encode the string.
For the first set of example parameters (ASCII only), the `parameter=value` string should look like this:
```
symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
After percent-encoding, the signature payload should look like this:
```
symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
For the second set of example parameters (some non-ASCII characters), the `parameter=value` string should look like this:
```
symbol=123456&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
After percent-encoding, the signature payload should look like this:
```
symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559
```
**Step 2: Compute the signature**
1. Use the `secretKey` of your API key as the signing key for the HMAC-SHA-256 algorithm.
2. Sign the signature payload constructed in Step 1.
3. Encode the HMAC-SHA-256 output as a hex string.
Note that `secretKey` and the payload are **case-sensitive**, while the resulting signature value is case-insensitive.
**Example commands**
For the first set of example parameters (ASCII only):
```
$ echo -n "symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n "symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559" | openssl dgst -sha256 -hmac "NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"e1353ec6b14d888f1164ae9af8228a3dbd508bc82eb867db8ab6046442f33ef3
```
**Step 3: Add signature to the request**
Complete the request by adding the `signature` parameter to the query string.
For the first set of example parameters (ASCII only):
```
curl -s -v -H "X-MBX-APIKEY: $apiKey" -X POST "https://testnet.binance.vision/api/v3/order?symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559&signature=c8db56825ae71d6d79447849e617115f4a920fa2acdcab2b053c4b2838bd6b71"
```
For the second set of example parameters (some non-ASCII characters)
```
curl -s -v -H "X-MBX-APIKEY: $apiKey" -X POST "https://testnet.binance.vision/api/v3/order?symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559&signature=e1353ec6b14d888f1164ae9af8228a3dbd508bc82eb867db8ab6046442f33ef3"
```
Here is a sample Bash script performing all the steps above:
```
apiKey="vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A"secretKey="NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j"payload="symbol=LTCBTC&side=BUY&type=LIMIT&timeInForce=GTC&quantity=1&price=0.1&recvWindow=5000&timestamp=1499827319559"# Sign the requestsignature=$(echo -n "$payload" | openssl dgst -sha256 -hmac "$secretKey")signature=${signature#*= } # Keep only the part after the "= "# Send the requestcurl -H "X-MBX-APIKEY: $apiKey" -X POST "https://testnet.binance.vision/api/v3/order?$payload&signature=$signature"
```
#### RSA Keys[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
The signature payload of your request is the query string concatenated without separator to the HTTP body. Any non-ASCII character must be percent-encoded before signing.
To get your API key, you need to upload your RSA Public Key to your account and a corresponding API key will be provided for you.
Only `PKCS#8` keys are supported.
There is one example with a symbol name comprised entirely of ASCII characters and one example with a symbol name containing non-ASCII characters.
These examples assume the private key is stored in the file `./test-prv-key.pem`.
Key
Value
`apiKey`
CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ
Example of request with a symbol name comprised entirely of ASCII characters:
Parameter
Value
`symbol`
BTCUSDT
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
Example of a request with a symbol name containing non-ASCII characters:
Parameter
Value
`symbol`
123456
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
**Step 1: Construct the signature payload**
1. Format parameters as `parameter=value` pairs separated by `&`.
2. Percent-encode the string.
For the first set of example parameters (ASCII only), the `parameter=value` string should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
For the second set of example parameters (some non-ASCII characters), the `parameter=value` string should look like this:
```
symbol=123456=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
**Step 2: Compute the signature**
1. Sign the signature payload constructed in Step 1 using the RSASSA-PKCS1-v1\_5 algorithm with SHA-256 hash function.
2. Encode the output in base64.
Note that the payload and the resulting `signature` are **case-sensitive**.
For the first set of example parameters (ASCII only):
```
$ echo -n 'symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000' | openssl dgst -sha256 -sign ./test-prv-key.pem | openssl enc -base64 -A | tr -d '\n'HZ8HOjiJ1s/igS9JA+n7+7Ti/ihtkRF5BIWcPIEluJP6tlbFM/Bf44LfZka/iemtahZAZzcO9TnI5uaXh3++lrqtNonCwp6/245UFWkiW1elpgtVAmJPbogcAv6rSlokztAfWk296ZJXzRDYAtzGH0gq7CgSJKfH+XxaCmR0WcvlKjNQnp12/eKXJYO4tDap8UCBLuyxDnR7oJKLHQHJLP0r0EAVOOSIbrFang/1WOq+Jaq4Efc4XpnTgnwlBbWTmhWDR1pvS9iVEzcSYLHT/fNnMRxFc7u+j3qI//5yuGuu14KR0MuQKKCSpViieD+fIti46sxPTsjSemoUKp0oXA==
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n 'symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000' | openssl dgst -sha256 -sign ./test-prv-key.pem | openssl enc -base64 -A | tr -d '\n'qJtv66wyp/1mZE+mIFAAMUoTe8xkmLN7/eAZjuC9x1ocxovItHLl/sNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M+JNIMz5UFxfeA53rXjFlvsyH1Sig+OuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C/QMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt/GuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng==
```
3. Percent-encode the base64 string.
For the first set of example parameters (ASCII only):
```
HZ8HOjiJ1s%2FigS9JA%2Bn7%2B7Ti%2FihtkRF5BIWcPIEluJP6tlbFM%2FBf44LfZka%2FiemtahZAZzcO9TnI5uaXh3%2B%2BlrqtNonCwp6%2F245UFWkiW1elpgtVAmJPbogcAv6rSlokztAfWk296ZJXzRDYAtzGH0gq7CgSJKfH%2BXxaCmR0WcvlKjNQnp12%2FeKXJYO4tDap8UCBLuyxDnR7oJKLHQHJLP0r0EAVOOSIbrFang%2F1WOq%2BJaq4Efc4XpnTgnwlBbWTmhWDR1pvS9iVEzcSYLHT%2FfNnMRxFc7u%2Bj3qI%2F%2F5yuGuu14KR0MuQKKCSpViieD%2BfIti46sxPTsjSemoUKp0oXA%3D%3D
```
For the second set of example parameters (some non-ASCII characters):
```
qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D
```
**Step 3: Add signature to the request**
Complete the request by adding the `signature` parameter to the query string.
For the first set of example parameters (ASCII only):
```
curl -H "X-MBX-APIKEY: CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ" -X POST 'https://testnet.binance.vision/api/v3/order?symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=HZ8HOjiJ1s%2FigS9JA%2Bn7%2B7Ti%2FihtkRF5BIWcPIEluJP6tlbFM%2FBf44LfZka%2FiemtahZAZzcO9TnI5uaXh3%2B%2BlrqtNonCwp6%2F245UFWkiW1elpgtVAmJPbogcAv6rSlokztAfWk296ZJXzRDYAtzGH0gq7CgSJKfH%2BXxaCmR0WcvlKjNQnp12%2FeKXJYO4tDap8UCBLuyxDnR7oJKLHQHJLP0r0EAVOOSIbrFang%2F1WOq%2BJaq4Efc4XpnTgnwlBbWTmhWDR1pvS9iVEzcSYLHT%2FfNnMRxFc7u%2Bj3qI%2F%2F5yuGuu14KR0MuQKKCSpViieD%2BfIti46sxPTsjSemoUKp0oXA%3D%3D'
```
For the second set of example parameters (some non-ASCII characters):
```
curl -H "X-MBX-APIKEY: CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ" -X POST 'https://testnet.binance.vision/api/v3/order?symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D'
```
Here is a sample Bash script performing all the steps above:
```
function rawurlencode { local string="${1}" local strlen=${#string} local encoded="" local pos c o for (( pos=0 ; pos<strlen ; pos++ )); do c=${string:$pos:1} case "$c" in [-_.~a-zA-Z0-9] ) o="${c}" ;; * ) printf -v o '%%%02x' "'$c" esac encoded+="${o}" done echo "${encoded}"}API_KEY="put your own API Key here"PRIVATE_KEY_PATH="test-prv-key.pem"# Set up the request:API_METHOD="POST"API_CALL="api/v3/order"API_PARAMS="symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2"# Sign the request:timestamp=$(date +%s000)api_params_with_timestamp="$API_PARAMS&timestamp=$timestamp"rawSignature=$(echo -n $api_params_with_timestamp | openssl dgst -keyform PEM -sha256 -sign $PRIVATE_KEY_PATH | openssl enc -base64 | tr -d '\n')# Percent-encode the signaturesignature=$(rawurlencode "$rawSignature")# Send the request:curl -H "X-MBX-APIKEY: $API_KEY" -X "$API_METHOD" \ "https://testnet.binance.vision/$API_CALL?$api_params_with_timestamp" \ --data-urlencode "signature=$signature"
```
#### Ed25519 Keys[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
**Note: It is highly recommended to use Ed25519 API keys as it should provide the best performance and security out of all supported key types.**
The signature payload of your request is the query string concatenated without separator to the HTTP body. Any non-ASCII character must be percent-encoded before signing.
There is one example with a symbol name comprised entirely of ASCII characters and one example with a symbol name containing non-ASCII characters.
These examples assume the private key is stored in the file `./test-prv-key.pem`.
Key
Value
`apiKey`
4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO
Example of request with a symbol name comprised entirely of ASCII characters.
Parameter
Value
`symbol`
BTCUSDT
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
Example of a request with a symbol name containing non-ASCII characters.
Parameter
Value
`symbol`
123456
`side`
SELL
`type`
LIMIT
`timeInForce`
GTC
`quantity`
1
`price`
0.2
`timestamp`
1668481559918
`recvWindow`
5000
**Step 1: Construct the signature payload**
1. Format parameters as `parameter=value` pairs separated by `&`.
2. Percent-encode the string.
For the first set of example parameters (ASCII only), the `parameter=value` string should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
For the second set of example parameters (some non-ASCII characters), the `parameter=value` string should look like this:
```
symbol=123456&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
After percent-encoding, the signature payload should look like this:
```
symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000
```
**Step 2: Compute the signature**
1. Sign the payload.
2. Encode the output as a base64 string.
Note that the payload and the resulting `signature` are **case-sensitive**.
For the first set of example parameters (ASCII only):
```
echo -n "symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000" | openssl dgst -keyform PEM -sha256 -sign ./test-prv-key.pem | openssl enc -base64 | tr -d '\n'HaZnek7KOGa/k5+f6Q1nw8lzMUpo36mRVvvLHCMUCXxlmdQQGZge1luAUKnleD/DYeD19YrqzeHbb6xU3MkSIXKhAO1MaYq48uGVYb3vJScEZVOutgMInrZzUcCWNulNkfcbmExSiymCZ5xQBw5QDuzpuDFqRZ1Xt+BZxEHBN9OYQKpoe0+ovjnXyVOaH8VUKhE/ghUWnThrXJr+hmSc5t7ggjiVPQc7pGn3qSNGCQwdpkQC9GHMr/r+8n6qeEKMYB5j/1wC4d8Jae8FQiU8xcXR0NlUgV2LAw61/ZJv5BTJpa+z5Lv1W9v6jHQWRX2O8uaG3KU/lR3spR7+oGlWOw=
```
For the second set of example parameters (some non-ASCII characters):
```
echo -n "symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000" | openssl dgst -keyform PEM -sha256 -sign ./test-prv-key.pem | openssl enc -base64 | tr -d '\n'qJtv66wyp/1mZE+mIFAAMUoTe8xkmLN7/eAZjuC9x1ocxovItHLl/sNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M+JNIMz5UFxfeA53rXjFlvsyH1Sig+OuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C/QMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt/GuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng==
```
3. Percent-encode the base64 string.
For the first set of example parameters (ASCII only):
```
HaZnek7KOGa%2Fk5%2Bf6Q1nw8lzMUpo36mRVvvLHCMUCXxlmdQQGZge1luAUKnleD%2FDYeD19YrqzeHbb6xU3MkSIXKhAO1MaYq48uGVYb3vJScEZVOutgMInrZzUcCWNulNkfcbmExSiymCZ5xQBw5QDuzpuDFqRZ1Xt%2BBZxEHBN9OYQKpoe0%2BovjnXyVOaH8VUKhE%2FghUWnThrXJr%2BhmSc5t7ggjiVPQc7pGn3qSNGCQwdpkQC9GHMr%2Fr%2B8n6qeEKMYB5j%2F1wC4d8Jae8FQiU8xcXR0NlUgV2LAw61%2FZJv5BTJpa%2Bz5Lv1W9v6jHQWRX2O8uaG3KU%2FlR3spR7%2BoGlWOw%3D
```
For the second set of example parameters (some non-ASCII characters):
```
qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D
```
**Step 3: Add signature to the request**
Complete the request by adding the `signature` parameter to the query string.
For the first set of example parameters (ASCII only):
```
curl -H "X-MBX-APIKEY: 4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO" -X POST 'hhttps://testnet.binance.vision/api/v3/order?symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=HaZnek7KOGa%2Fk5%2Bf6Q1nw8lzMUpo36mRVvvLHCMUCXxlmdQQGZge1luAUKnleD%2FDYeD19YrqzeHbb6xU3MkSIXKhAO1MaYq48uGVYb3vJScEZVOutgMInrZzUcCWNulNkfcbmExSiymCZ5xQBw5QDuzpuDFqRZ1Xt%2BBZxEHBN9OYQKpoe0%2BovjnXyVOaH8VUKhE%2FghUWnThrXJr%2BhmSc5t7ggjiVPQc7pGn3qSNGCQwdpkQC9GHMr%2Fr%2B8n6qeEKMYB5j%2F1wC4d8Jae8FQiU8xcXR0NlUgV2LAw61%2FZJv5BTJpa%2Bz5Lv1W9v6jHQWRX2O8uaG3KU%2FlR3spR7%2BoGlWOw%3D'
```
For the second set of example parameters (some non-ASCII characters):
```
curl -H "X-MBX-APIKEY: 4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO" -X POST 'https://testnet.binance.vision/api/v3/order?symbol=%EF%BC%91%EF%BC%92%EF%BC%93%EF%BC%94%EF%BC%95%EF%BC%96&&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2&timestamp=1668481559918&recvWindow=5000&signature=qJtv66wyp%2F1mZE%2BmIFAAMUoTe8xkmLN7%2FeAZjuC9x1ocxovItHLl%2FsNK7Wq8QjgiHqGn0bb8P7yVvGBEd1gFe71NQ8aM0M%2BJNIMz5UFxfeA53rXjFlvsyH1Sig%2BOuO9Nz5nhCaJ6bEfj2iuv7w27pB3L8MVqmoCi6D9C%2FQMiLxtPaR70CxtnvoOlIgPmpv2bQy029A31NEK19ieVLkoyp1EUkXRaX3v0mohx8yMnUG1dhX9nUg3Oy8TYZ03DQy7kHDGkMKisNX7rt%2FGuGx1HIgjFclDGLsbAFIodvSLjm9FbseasMELoxlAJDlwRnW8zo5sQmL0Fz7ao935QBynrng%3D%3D'
```
Here is a sample Python script performing all the steps above:
```
#!/usr/bin/env python3import base64import requestsimport timeimport urllib.parsefrom cryptography.hazmat.primitives.serialization import load_pem_private_key# Set up authenticationAPI_KEY='put your own API Key here'PRIVATE_KEY_PATH='test-prv-key.pem'# Load the private key.# In this example the key is expected to be stored without encryption,# but we recommend using a strong password for improved security.with open(PRIVATE_KEY_PATH, 'rb') as f: private_key = load_pem_private_key(data=f.read(), password=None)# Set up the request parametersparams = { 'symbol': 'BTCUSDT', 'side': 'SELL', 'type': 'LIMIT', 'timeInForce': 'GTC', 'quantity': '1.0000000', 'price': '0.20',}# Timestamp the requesttimestamp = int(time.time() * 1000) # UNIX timestamp in millisecondsparams['timestamp'] = timestamp# Sign the requestpayload = urllib.parse.urlencode(params, encoding='UTF-8')signature = base64.b64encode(private_key.sign(payload.encode('ASCII')))params['signature'] = signature# Send the requestheaders = { 'X-MBX-APIKEY': API_KEY,}response = requests.post( 'https://testnet.binance.vision/api/v3/order', headers=headers, data=params,)print(response.json())
```
- [SIGNED Endpoint security](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
- [Timing security](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
- [SIGNED Endpoint Examples for POST /api/v3/order](https://developers.binance.com/docs/binance-spot-api-docs/testnet/rest-api/request-security)
File diff suppressed because it is too large Load Diff
@@ -1,99 +0,0 @@
---
title: "SBE Market Data | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams"
fetched_at: "2026-02-26T10:38:10.990Z"
---
# SBE Market Data Streams
## General Information[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- The base endpoint is **stream-sbe.testnet.binance.vision** or **stream-sbe.testnet.binance.vision:9443**.
- To retrieve market data in JSON format, please refer to [this page](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams).
- SBE schema used for decoding the streams can be found [here](https://github.com/binance/binance-spot-api-docs/blob/master/sbe/schemas/stream_1_0.xml).
- All symbols in stream names are **lowercase**.
- You can subscribe to a single stream at **/ws/<streamName>**.
- You can subscribe to multiple streams at **/stream?streams=<streamName1>/<streamName2>/<streamName3>**.
- A single connection to **stream-sbe.testnet.binance.vision** is **only valid for 24 hours**; expect to be disconnected at the 24 hour mark.
- All time and timestamp fields are in **microseconds**.
- **An API Key is necessary for access**.
- Only Ed25519 keys are allowed.
- Please put your API Key in the `X-MBX-APIKEY` header when opening the connection. Timestamp and signature are not necessary.
- No extra API key permissions are necessary to access public market data. Symbol whitelist also does not affect access to SBE Market Data Streams.
- However, if you use an IP whitelist for the API key, only specified IP addresses are allowed to use the API key.
- The server sends a `ping frame` every 20 seconds.
- If the server does not receive a `pong frame` back from you within a minute, the connection will be closed.
- When you receive a ping, you must send a pong with a copy of ping's payload as soon as possible.
- Unsolicited `pong frames` are allowed, but will not prevent disconnection. **It is recommended that the payload for these pong frames are empty.**
- [Live Subscribing and Unsubscribing](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams) is also supported.
- You must send the subscription requests in JSON, and will receive the subscription response also in JSON.
- You can differentiate subscription responses from market data events by looking at the WebSocket frame type: subscription responses are always sent in text frames (containing JSON), and events are always sent in binary frames (containing SBE).
## WebSocket Limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- WebSocket connections have a rate limit of **5 requests per second**.
- Only messages from your client are considered:
- `PING frame`
- `PONG frame`
- `Text frame` with JSON control request
- Events pushed by the server are not rate-limited.
- Connections that go beyond the limit will be closed. Repeatedly disconnected IP addresses may be banned.
- A single connection can listen to a maximum of 1024 streams.
- There is a limit of **300 connection attempts every 5 minutes per IP address**.
## Available Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
### Trades Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
Raw trade information, pushed in real-time.
**SBE Message Name:** `TradesStreamEvent`
**Stream Name**: <symbol>@trade
**Update Speed**: Real time
### Best Bid/Ask Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
The best bid and ask price and quantity, pushed in real-time when the order book changes.
> \[!NOTE\] Best bid/ask streams in SBE are the equivalent of bookTicker streams in JSON, except they support auto-culling, and also include the `eventTime` field.
**SBE Message Name:** `BestBidAskStreamEvent`
**Stream Name**: <symbol>@bestBidAsk
**Update Speed**: Real time
SBE best bid/ask streams use **auto-culling**: when the system is under high load, it may drop outdated events instead of queuing all events and delivering them with a delay.
For example, if a best bid/ask event is generated at time T2 when there is still an undelivered event queued at time T1 (where T1 < T2), the event for T1 is dropped, and the system will deliver only the event for T2. This is done on a per-symbol basis.
### Diff. Depth Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
Incremental updates to the order book, pushed at regular intervals. Use this stream to maintain a local order book.
[How to manage a local order book.](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
**SBE Message Name:** `DepthDiffStreamEvent`
**Stream Name**: <symbol>@depth
**Update Speed:** 50ms
### Partial Book Depth Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
Snapshots of the top 20 levels of the order book, pushed at regular intervals.
**SBE Message Name:** `DepthSnapshotStreamEvent`
**Stream Name**: <symbol>@depth20
**Update Speed:** 50ms
- [General Information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- [WebSocket Limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- [Available Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- [Trades Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- [Best Bid/Ask Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- [Diff. Depth Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
- [Partial Book Depth Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/sbe-market-data-streams)
@@ -1,293 +0,0 @@
---
title: "User Data Stream | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream"
fetched_at: "2026-02-26T10:38:11.022Z"
---
# User Data Streams for Binance Spot TESTNET
## General information[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- Subscribe via the [WebSocket API](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests) using an API Key.
- Both [SBE](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) and JSON output are supported.
- Account events are pushed in **real-time**.
- All timestamps in JSON payloads are in **milliseconds by default**.
- Events may contain non-ASCII characters encoded in UTF-8 if you own or trade any assets or symbols whose names contain non-ASCII characters.
## User Data Stream Events[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
### Account Update[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
`outboundAccountPosition` is sent any time an account balance has changed and contains the assets that were possibly changed by the event that generated the balance change.
```
{ "subscriptionId": 0, "event": { "e": "outboundAccountPosition", // Event type "E": 1564034571105, // Event Time "u": 1564034571073, // Time of last account update // Balances Array "B": [ { "a": "ETH", // Asset "f": "10000.000000", // Free "l": "0.000000" // Locked } ] }}
```
### Balance Update[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
Balance Update occurs during the following:
- Deposits or withdrawals from the account
- Transfer of funds between accounts (e.g. Spot to Margin)
**Payload**
```
{ "subscriptionId": 0, "event": { "e": "balanceUpdate", // Event Type "E": 1573200697110, // Event Time "a": "BTC", // Asset "d": "100.00000000", // Balance Delta "T": 1573200697068 // Clear Time }}
```
### Order Update[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
Orders are updated with the `executionReport` event.
**Payload:**
```
{ "subscriptionId": 0, "event": { "e": "executionReport", // Event type "E": 1499405658658, // Event time "s": "ETHBTC", // Symbol "c": "mUvoqJxFIILMdfAW5iGSOW", // Client order ID "S": "BUY", // Side "o": "LIMIT", // Order type "f": "GTC", // Time in force "q": "1.00000000", // Order quantity "p": "0.10264410", // Order price "P": "0.00000000", // Stop price "F": "0.00000000", // Iceberg quantity "g": -1, // OrderListId "C": "", // Original client order ID; This is the ID of the order being canceled "x": "NEW", // Current execution type "X": "NEW", // Current order status "r": "NONE", // Order reject reason; Please see Order Reject Reason (below) for more information. "i": 4293153, // Order ID "l": "0.00000000", // Last executed quantity "z": "0.00000000", // Cumulative filled quantity "L": "0.00000000", // Last executed price "n": "0", // Commission amount "N": null, // Commission asset "T": 1499405658657, // Transaction time "t": -1, // Trade ID "v": 3, // Prevented Match Id; This is only visible if the order expired due to STP "I": 8641984, // Execution Id "w": true, // Is the order on the book? "m": false, // Is this trade the maker side? "M": false, // Ignore "O": 1499405658657, // Order creation time "Z": "0.00000000", // Cumulative quote asset transacted quantity "Y": "0.00000000", // Last quote asset transacted quantity (i.e. lastPrice * lastQty) "Q": "0.00000000", // Quote Order Quantity "W": 1499405658657, // Working Time; This is only visible if the order has been placed on the book. "V": "NONE" // SelfTradePreventionMode }}
```
**Note:** Average price can be found by doing `Z` divided by `z`.
#### Conditional Fields in Execution Report[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
These are fields that appear in the payload only if certain conditions are met.
For additional information on these parameters, please refer to the [Spot Glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary).
Field
Name
Description
Examples
`d`
Trailing Delta
Appears only for trailing stop orders.
`"d": 4`
`D`
Trailing Time
`"D": 1668680518494`
`j`
Strategy Id
Appears only if the `strategyId` parameter was provided upon order placement.
`"j": 1`
`J`
Strategy Type
Appears only if the `strategyType` parameter was provided upon order placement.
`"J": 1000000`
`v`
Prevented Match Id
Appears only for orders that expired due to STP.
`"v": 3`
`A`
Prevented Quantity
`"A":"3.000000"`
`B`
Last Prevented Quantity
`"B":"3.000000"`
`u`
Trade Group Id
`"u":1`
`U`
Counter Order Id
`"U":37`
`Cs`
Counter Symbol
`"Cs": "BTCUSDT"`
`pl`
Prevented Execution Quantity
`"pl":"2.123456"`
`pL`
Prevented Execution Price
`"pL":"0.10000001"`
`pY`
Prevented Execution Quote Qty
`"pY":"0.21234562"`
`W`
Working Time
Appears when the order is working on the book
`"W": 1668683798379`
`b`
Match Type
Appears for orders that have allocations
`"b":"ONE_PARTY_TRADE_REPORT"`
`a`
Allocation ID
`"a":1234`
`k`
Working Floor
Appears for orders that potentially have allocations
`"k":"SOR"`
`uS`
UsedSor
Appears for orders that used SOR
`"uS":true`
`gP`
Pegged Price Type
Appears only for Pegged Orders
`"gP": "PRIMARY_PEG"`
`gOT`
Pegged offset Type
`"gOT": "PRICE_LEVEL"`
`gOV`
Pegged Offset Value
`"gOV": 5`
`gp`
Pegged Price
`"gp": "1.00000000"`
#### Order Reject Reason[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
For additional details, look up the Error Message in the [Errors](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors) documentation.
Rejection Reason (`r`)
Error Message
`NONE`
N/A (i.e. The order was not rejected.)
`INSUFFICIENT_BALANCES`
"Account has insufficient balance for requested action."
`STOP_PRICE_WOULD_TRIGGER_IMMEDIATELY`
"Order would trigger immediately."
`WOULD_MATCH_IMMEDIATELY`
"Order would immediately match and take."
`OCO_BAD_PRICES`
"The relationship of the prices for the orders is not correct."
If the order is an order list, an event named `ListStatus` will be sent in addition to the `executionReport` event.
**Payload**
```
{ "subscriptionId": 0, "event": { "e": "listStatus", // Event Type "E": 1564035303637, // Event Time "s": "ETHBTC", // Symbol "g": 2, // OrderListId "c": "OCO", // Contingency Type "l": "EXEC_STARTED", // List Status Type "L": "EXECUTING", // List Order Status "r": "NONE", // List Reject Reason "C": "F4QN4G8DlFATFlIUQ0cjdD", // List Client Order ID "T": 1564035303625, // Transaction Time // An array of objects "O": [ { "s": "ETHBTC", // Symbol "i": 17, // OrderId "c": "AJYsMjErWJesZvqlJCTUgL" // ClientOrderId }, { "s": "ETHBTC", "i": 18, "c": "bfYPSQdLoqAJeNrOr9adzq" } ] }}
```
#### Execution types[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- `NEW` - The order has been accepted into the engine.
- `CANCELED` - The order has been canceled by the user.
- `REPLACED` - The order has been amended.
- `REJECTED` - The order has been rejected and was not processed. (e.g. Cancel Replace orders where the new order placement was rejected even if the cancel request succeeded.)
- `TRADE` - Part of the order or all of the order's quantity has filled.
- `EXPIRED` - The order was canceled according to the order type's rules (e.g. LIMIT FOK orders with no fill, LIMIT IOC or MARKET orders that partially fill) or by the exchange, (e.g. orders canceled during liquidation, orders canceled during maintenance).
- `TRADE_PREVENTION` - The order has expired due to STP.
Check the [Enums Documentation](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums) for more relevant enum definitions.
### Event Stream Terminated[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
`eventStreamTerminated` is sent when:
- [A listen token subscription](https://developers.binance.com/docs/margin_trading/trade-data-stream/Listen-Token-Websocket-API) expires due to token expiration.
- A [logon subscription](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests) ends after sending [`session.logout`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests) method.
- The subscription is stopped via the [`userDataStream.unsubscribe`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests) method.
**Payload:**
```
{ "subscriptionId": 0, "event": { "e": "eventStreamTerminated", // Event Type "E": 1728973001334 // Event Time }}
```
### External Lock Update[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
`externalLockUpdate` is sent when part of your spot wallet balance is locked/unlocked by an external system, for example when used as margin collateral.
**Payload:**
```
{ "subscriptionId": 0, "event": { "e": "externalLockUpdate", // Event Type "E": 1581557507324, // Event Time "a": "NEO", // Asset "d": "10.00000000", // Delta "T": 1581557507268 // Transaction Time }}
```
- [General information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- [User Data Stream Events](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- [Account Update](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- [Balance Update](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- [Order Update](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- [Event Stream Terminated](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
- [External Lock Update](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
@@ -1,434 +0,0 @@
---
title: "WebSocket Streams | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams"
fetched_at: "2026-02-26T10:38:11.267Z"
---
# WebSocket Streams for Binance SPOT Testnet
## General WSS information[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- The base endpoint is: **wss://stream.testnet.binance.vision/ws**.
- 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>}**
- All symbols for streams are **lowercase**
- All time and timestamp related fields are **milliseconds by default**. To receive the information in microseconds, please add the parameter `timeUnit=MICROSECOND` or `timeUnit=microsecond` in the URL.
- For example: `/stream?streams=btcusdt@trade&timeUnit=MICROSECOND`
- A single connection to **stream.binance.com** is only valid for 24 hours; expect to be disconnected at the 24 hour mark
- The WebSocket server will send a `ping frame` every 20 seconds.
- If the WebSocket server does not receive a `pong frame` back from the connection within a minute, the connection will be disconnected.
- When you receive a ping, you must send a pong with a copy of ping's payload as soon as possible.
- Unsolicited `pong frames` are allowed, but will not prevent disconnection. **It is recommended that the payload for these pong frames are empty.**
- The base endpoint **wss://data-stream.binance.vision** can be subscribed to receive **only** market data messages.
User data stream is **NOT** available from this URL.
- All time and timestamp related fields are **milliseconds by default**. To receive the information in microseconds, please add the parameter `timeUnit=MICROSECOND or timeUnit=microsecond` in the URL.
- For example: `/stream?streams=btcusdt@trade&timeUnit=MICROSECOND`
- If your request contains a symbol name containing non-ASCII characters, then the stream events may contain non-ASCII characters encoded in UTF-8.
- \[All Market Mini Tickers Stream\](#all-market-mini-tickers-stream and [All Market Rolling Window Statistics Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams) events may contain non-ASCII characters encoded in UTF-8.
## WebSocket Limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- WebSocket connections have a limit of 5 incoming messages per second. A message is considered:
- A PING frame
- A PONG frame
- A JSON controlled 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.
- There is a limit of **300 connections per attempt every 5 minutes per IP**.
## Live Subscribing/Unsubscribing to streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-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` is used as an identifier to uniquely identify the messages going back and forth. The following formats are accepted:
- 64-bit signed integer
- alphanumeric strings; max length 36
- `null`
- 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[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- Request
```
{ "method": "SUBSCRIBE", "params": ["btcusdt@aggTrade", "btcusdt@depth"], "id": 1}
```
- Response
```
{ "result": null, "id": 1}
```
### Unsubscribe to a stream[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- Request
```
{ "method": "UNSUBSCRIBE", "params": ["btcusdt@depth"], "id": 312}
```
- Response
```
{ "result": null, "id": 312}
```
### Listing Subscriptions[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- Request
```
{ "method": "LIST_SUBSCRIPTIONS", "id": 3}
```
- Response
```
{ "result": ["btcusdt@aggTrade"], "id": 3}
```
### Setting Properties[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
Currently, the only property that can be set is whether `combined` stream payloads are enabled or 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[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- Request
```
{ "method": "GET_PROPERTY", "params": ["combined"], "id": 2}
```
- Response
```
{ "result": true, // Indicates that combined is set to true. "id": 2}
```
### Error Messages[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
Error Message
Description
{"code": 0, "msg": "Unknown property","id": %s}
Parameter used in the `SET_PROPERTY` or `GET_PROPERTY` was invalid
{"code": 1, "msg": "Invalid value type: expected Boolean"}
Value should only be `true` or `false`
{"code": 2, "msg": "Invalid request: property name must be a string"}
Property name provided was invalid
{"code": 2, "msg": "Invalid request: request ID must be an unsigned integer"}
Parameter `id` had to be provided or the value provided in the `id` parameter is an unsupported type
{"code": 2, "msg": "Invalid request: unknown variant %s, expected one of `SUBSCRIBE`, `UNSUBSCRIBE`, `LIST_SUBSCRIPTIONS`, `SET_PROPERTY`, `GET_PROPERTY` at line 1 column 28"}
Possible typo in the provided method or provided method was neither of the expected values
{"code": 2, "msg": "Invalid request: too many parameters"}
Unnecessary parameters provided in the data
{"code": 2, "msg": "Invalid request: property name must be a string"}
Property name was not provided
{"code": 2, "msg": "Invalid request: missing field `method` at line 1 column 73"}
`method` was not provided in the data
{"code":3,"msg":"Invalid JSON: expected value at line %s column %s"}
JSON data sent has incorrect syntax.
# Detailed Stream information
## Aggregate Trade Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-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:**
```
{ "e": "aggTrade", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "a": 12345, // Aggregate trade ID "p": "0.001", // Price "q": "100", // Quantity "f": 100, // First trade ID "l": 105, // Last trade ID "T": 1672515782136, // Trade time "m": true, // Is the buyer the market maker? "M": true // Ignore}
```
## Trade Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-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:**
```
{ "e": "trade", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "t": 12345, // Trade ID "p": "0.001", // Price "q": "100", // Quantity "T": 1672515782136, // Trade time "m": true, // Is the buyer the market maker? "M": true // Ignore}
```
## Kline/Candlestick Streams for UTC[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
The Kline/Candlestick Stream push updates to the current klines/candlestick every second in `UTC+0` timezone.
**Kline/Candlestick chart intervals:**
s-> seconds; m -> minutes; h -> hours; d -> days; w -> weeks; M -> months
- 1s
- 1m
- 3m
- 5m
- 15m
- 30m
- 1h
- 2h
- 4h
- 6h
- 8h
- 12h
- 1d
- 3d
- 1w
- 1M
**Stream Name:** <symbol>@kline\_<interval>
**Update Speed:** 1000ms for `1s`, 2000ms for the other intervals
**Payload:**
```
{ "e": "kline", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "k": { "t": 1672515780000, // Kline start time "T": 1672515839999, // Kline close time "s": "BNBBTC", // Symbol "i": "1m", // Interval "f": 100, // First trade ID "L": 200, // Last trade ID "o": "0.0010", // Open price "c": "0.0020", // Close price "h": "0.0025", // High price "l": "0.0015", // Low price "v": "1000", // Base asset volume "n": 100, // Number of trades "x": false, // Is this kline closed? "q": "1.0000", // Quote asset volume "V": "500", // Taker buy base asset volume "Q": "0.500", // Taker buy quote asset volume "B": "123456" // Ignore }}
```
## Kline/Candlestick Streams with timezone offset[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
The Kline/Candlestick Stream push updates to the current klines/candlestick every second in `UTC+8` timezone.
**Kline/Candlestick chart intervals:** Supported intervals: See [`Kline/Candlestick chart intervals`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
**UTC+8 timezone offset:**
- Kline intervals open and close in the `UTC+8` timezone. For example the `1d` klines will open at the beginning of the `UTC+8` day, and close at the end of the `UTC+8` day.
- Note that `E` (event time), `t` (start time), and `T` (close time) in the payload are Unix timestamps, which are always interpreted in UTC.
**Stream Name:** <symbol>@kline\_<interval>@+08:00
**Update Speed:** 1000ms for `1s`, 2000ms for the other intervals
**Payload:**
```
{ "e": "kline", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "k": { "t": 1672515780000, // Kline start time "T": 1672515839999, // Kline close time "s": "BNBBTC", // Symbol "i": "1m", // Interval "f": 100, // First trade ID "L": 200, // Last trade ID "o": "0.0010", // Open price "c": "0.0020", // Close price "h": "0.0025", // High price "l": "0.0015", // Low price "v": "1000", // Base asset volume "n": 100, // Number of trades "x": false, // Is this kline closed? "q": "1.0000", // Quote asset volume "V": "500", // Taker buy base asset volume "Q": "0.500", // Taker buy quote asset volume "B": "123456" // Ignore }}
```
## Individual Symbol Mini Ticker Stream[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
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:**
```
{ "e": "24hrMiniTicker", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "c": "0.0025", // Close price "o": "0.0010", // Open price "h": "0.0025", // High price "l": "0.0010", // Low price "v": "10000", // Total traded base asset volume "q": "18" // Total traded quote asset volume}
```
## All Market Mini Tickers Stream[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
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:**
```
[ { // Same as <symbol>@miniTicker payload }]
```
## Individual Symbol Ticker Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
24hr rolling window ticker statistics for a single symbol. These are NOT the statistics of the UTC day, but a 24hr rolling window for the previous 24hrs.
**Stream Name:** <symbol>@ticker
**Update Speed:** 1000ms
**Payload:**
```
{ "e": "24hrTicker", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "p": "0.0015", // Price change "P": "250.00", // Price change percent "w": "0.0018", // Weighted average price "x": "0.0009", // First trade(F)-1 price (first trade before the 24hr rolling window) "c": "0.0025", // Last price "Q": "10", // Last quantity "b": "0.0024", // Best bid price "B": "10", // Best bid quantity "a": "0.0026", // Best ask price "A": "100", // Best ask quantity "o": "0.0010", // Open price "h": "0.0025", // High price "l": "0.0010", // Low price "v": "10000", // Total traded base asset volume "q": "18", // Total traded quote asset volume "O": 0, // Statistics open time "C": 86400000, // Statistics close time "F": 0, // First trade ID "L": 18150, // Last trade Id "n": 18151 // Total number of trades}
```
## Individual Symbol Rolling Window Statistics Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
Rolling window ticker statistics for a single symbol, computed over multiple windows.
**Stream Name:** <symbol>@ticker\_<window\_size>
**Window Sizes:** 1h,4h,1d
**Update Speed:** 1000ms
**Note**: This stream is different from the <symbol>@ticker stream. The open time `O` always starts on a minute, while the closing time `C` is the current time of the update. As such, the effective window might be up to 59999ms wider that <window\_size>.
**Payload:**
```
{ "e": "1hTicker", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "p": "0.0015", // Price change "P": "250.00", // Price change percent "o": "0.0010", // Open price "h": "0.0025", // High price "l": "0.0010", // Low price "c": "0.0025", // Last price "w": "0.0018", // Weighted average price "v": "10000", // Total traded base asset volume "q": "18", // Total traded quote asset volume "O": 0, // Statistics open time "C": 1675216573749, // Statistics close time "F": 0, // First trade ID "L": 18150, // Last trade Id "n": 18151 // Total number of trades}
```
## All Market Rolling Window Statistics Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
Rolling window ticker statistics for all market symbols, computed over multiple windows. Note that only tickers that have changed will be present in the array.
**Stream Name:** !ticker\_<window-size>@arr
**Window Size:** 1h,4h,1d
**Update Speed:** 1000ms
**Payload:**
```
[ { // Same as <symbol>@ticker_<window-size> payload, // one for each symbol updated within the interval. }]
```
## Individual Symbol Book Ticker Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
Pushes any update to the best bid or ask's price or quantity in real-time for a specified symbol. Multiple `<symbol>@bookTicker` streams can be subscribed to over one connection.
**Stream Name:** <symbol>@bookTicker
**Update Speed:** Real-time
**Payload:**
```
{ "u": 400900217, // order book updateId "s": "BNBUSDT", // symbol "b": "25.35190000", // best bid price "B": "31.21000000", // best bid qty "a": "25.36520000", // best ask price "A": "40.66000000" // best ask qty}
```
## Average Price[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
Average price streams push changes in the average price over a fixed time interval.
**Stream Name:** <symbol>@avgPrice
**Update Speed:** 1000ms
**Payload:**
```
{ "e": "avgPrice", // Event type "E": 1693907033000, // Event time "s": "BTCUSDT", // Symbol "i": "5m", // Average price interval "w": "25776.86000000", // Average price "T": 1693907032213 // Last trade time}
```
## Partial Book Depth Streams[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-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:**
```
{ "lastUpdateId": 160, // Last update ID "bids": [ // Bids to be updated [ "0.0024", // Price level to be updated "10" // Quantity ] ], "asks": [ // Asks to be updated [ "0.0026", // Price level to be updated "100" // Quantity ] ]}
```
## Diff. Depth Stream[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
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:**
```
{ "e": "depthUpdate", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "U": 157, // First update ID in event "u": 160, // Final update ID in event "b": [ // Bids to be updated [ "0.0024", // Price level to be updated "10" // Quantity ] ], "a": [ // Asks to be updated [ "0.0026", // Price level to be updated "100" // Quantity ] ]}
```
## How to manage a local order book correctly[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
1. Open a WebSocket connection to `wss://stream.testnet.binance.vision:9443/ws/bnbbtc@depth`.
2. Buffer the events received from the stream. Note the `U` of the first event you received.
3. Get a depth snapshot from `https://testnet.binance.vision/api/v3/depth?symbol=BNBBTC&limit=5000`.
4. If the `lastUpdateId` from the snapshot is strictly less than the `U` from step 2, go back to step 3.
5. In the buffered events, discard any event where `u` is <= `lastUpdateId` of the snapshot. The first buffered event should now have `lastUpdateId` within its `[U;u]` range.
6. Set your local order book to the snapshot. Its update ID is `lastUpdateId`.
7. Apply the update procedure below to all buffered events, and then to all subsequent events received.
To apply an event to your local order book, follow this update procedure:
1. Decide whether the update event can be applied:
- If the event last update ID (`u`) is less than the update ID of your local order book, ignore the event.
- If the event first update ID (`U`) is greater than the update ID of your local order book + 1, you have missed some events.
Discard your local order book and restart the process from the beginning.
- Normally, `U` of the next event is equal to `u + 1` of the previous event.
2. For each price level in bids (`b`) and asks (`a`), set the new quantity in the order book:
- If the price level does not exist in the order book, insert it with new quantity.
- If the quantity is zero, remove the price level from the order book.
3. Set the order book update ID to the last update ID (`u`) in the processed event.
> \[!NOTE\] Since depth snapshots retrieved from the API have a limit on the number of price levels (5000 on each side maximum), you won't learn the quantities for the levels outside of the initial snapshot unless they change.
> So be careful when using the information for those levels, since they might not reflect the full view of the order book.
> However, for most use cases, seeing 5000 levels on each side is enough to understand the market and trade effectively.
- [General WSS information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [WebSocket Limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Live Subscribing/Unsubscribing to streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Subscribe to a stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Unsubscribe to a stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Listing Subscriptions](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Setting Properties](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Retrieving Properties](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Error Messages](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Aggregate Trade Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Trade Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Kline/Candlestick Streams for UTC](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Kline/Candlestick Streams with timezone offset](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Individual Symbol Mini Ticker Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [All Market Mini Tickers Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Individual Symbol Ticker Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Individual Symbol Rolling Window Statistics Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [All Market Rolling Window Statistics Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Individual Symbol Book Ticker Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Average Price](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Partial Book Depth Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [Diff. Depth Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
- [How to manage a local order book correctly](https://developers.binance.com/docs/binance-spot-api-docs/testnet/web-socket-streams)
File diff suppressed because it is too large Load Diff
@@ -1,111 +0,0 @@
---
title: "Authentication requests | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests"
fetched_at: "2026-02-26T10:38:11.272Z"
---
**Note:** Only _Ed25519_ keys are supported for this feature.
### Log in with API key (SIGNED)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests)
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "method": "session.logon", "params": { "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "1cf54395b336b0a9727ef27d5d98987962bc47aca6e13fe978612d0adee066ed", "timestamp": 1649729878532 }}
```
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
**Parameters:**
Name
Type
Mandatory
Description
`apiKey`
STRING
YES
`recvWindow`
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
`signature`
STRING
YES
`timestamp`
LONG
YES
**Data Source:** Memory
**Response:**
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "status": 200, "result": { "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "authorizedSince": 1649729878532, "connectedSince": 1649729873021, "returnRateLimits": false, "serverTime": 1649729878630, "userDataStream": false // is User Data Stream subscription active? }}
```
### Query session status[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests)
```
{ "id": "b50c16cd-62c9-4e29-89e4-37f10111f5bf", "method": "session.status"}
```
Query the status of the WebSocket connection, inspecting which API key (if any) is used to authorize requests.
**Weight:** 2
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "b50c16cd-62c9-4e29-89e4-37f10111f5bf", "status": 200, "result": { // if the connection is not authenticated, "apiKey" and "authorizedSince" will be shown as null "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "authorizedSince": 1649729878532, "connectedSince": 1649729873021, "returnRateLimits": false, "serverTime": 1649730611671, "userDataStream": true // is User Data Stream subscription active? }}
```
### Log out of the session[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests)
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "method": "session.logout"}
```
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
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "status": 200, "result": { "apiKey": null, "authorizedSince": null, "connectedSince": 1649729873021, "returnRateLimits": false, "serverTime": 1649730611671, "userDataStream": false // is User Data Stream subscription active? }}
```
- [Log in with API key (SIGNED)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests)
- [Query session status](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests)
- [Log out of the session](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests)
@@ -1,37 +0,0 @@
---
title: "Data sources | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/data-sources"
fetched_at: "2026-02-26T10:38:11.308Z"
---
- The API system is asynchronous. Some delay in the response is normal and expected.
- Each method has a data source indicating where the data is coming from, and thus how up-to-date it is.
Data Source
Latency
Description
Matching Engine
lowest
The Matching Engine produces the response directly
Memory
low
Data is fetched from API server's local or external memory cache
Database
moderate
Data is retrieved from the database
- Some methods have more than one data source (e.g., Memory => Database).
This means that the API will look for the latest data in that order: first in the cache, then in the database.
@@ -1,42 +0,0 @@
---
title: "Event format | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/event-format"
fetched_at: "2026-02-26T10:38:11.531Z"
---
[User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream) events for non-SBE sessions are sent as JSON in **text frames**, one event per frame.
Events in [SBE sessions](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) will be sent as **binary frames**.
Please refer to [`userDataStream.subscribe`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests) for details on how to subscribe to User Data Stream in WebSocket API.
Example of an event:
```
{ "subscriptionId": 0, "event": { "e": "outboundAccountPosition", "E": 1728972148778, "u": 1728972148778, "B": [ { "a": "BTC", "f": "11818.00000000", "l": "182.00000000" }, { "a": "USDT", "f": "10580.00000000", "l": "70.00000000" } ] }}
```
Event fields:
Name
Type
Mandatory
Description
`event`
OBJECT
YES
Event payload. See [User Data Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream)
`subscriptionId`
INT
NO
Identifies which subscription the event is coming from. See [User Data Stream subscriptions](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/event-format)
@@ -1,29 +0,0 @@
---
title: "General API Information | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-api-information"
fetched_at: "2026-02-26T10:38:11.524Z"
---
- The base endpoint is: **`wss://ws-api.testnet.binance.vision/ws-api/v3`**
- If you experience issues with the standard 443 port, alternative port 9443 is also available.
- A single connection to the API is only valid for 24 hours; expect to be disconnected after the 24-hour mark.
- We support HMAC, RSA, and Ed25519 keys. For more information, please see [API Key types](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types).
- Responses are in JSON by default. To receive responses in SBE, refer to the [SBE FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) page.
- If your request contains a symbol name containing non-ASCII characters, then the response may contain non-ASCII characters encoded in UTF-8.
- Some methods may return asset and/or symbol names containing non-ASCII characters encoded in UTF-8 even if the request did not contain non-ASCII characters.
- The WebSocket server will send a `ping frame` every 20 seconds.
- If the WebSocket server does not receive a `pong frame` back from the connection within a minute the connection will be disconnected.
- When you receive a ping, you must send a pong with a copy of ping's payload as soon as possible.
- Unsolicited `pong frames` are allowed, but will not prevent disconnection. **It is recommended that the payload for these pong frames are empty.**
- Data is returned in **chronological order**, unless noted otherwise.
- Without `startTime` or `endTime`, returns the most recent items up to the limit.
- With `startTime`, returns oldest items from `startTime` up to the limit.
- With `endTime`, returns most recent items up to `endTime` and the limit.
- With both, behaves like `startTime` but does not exceed `endTime`.
- All timestamps in the JSON responses are in **milliseconds in UTC by default**. To receive the information in microseconds, please add the parameter `timeUnit=MICROSECOND` or `timeUnit=microsecond` in the URL.
- Timestamp parameters (e.g. `startTime`, `endTime`, `timestamp`) can be passed in milliseconds or microseconds.
- All field names and values are **case-sensitive**, unless noted otherwise.
- If there are enums or terms you want clarification on, please see [SPOT Glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary) for more information.
- APIs have a timeout of 10 seconds when processing a request. If a response from the Matching Engine takes longer than this, the API responds with "Timeout waiting for response from backend server. Send status unknown; execution status unknown." [(-1007 TIMEOUT)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors)
- This does not always mean that the request failed in the Matching Engine.
- If the status of the request has not appeared in [User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream), please perform an API query for its status.
- **Please avoid SQL keywords in requests** as they may trigger a security block by a WAF (Web Application Firewall) rule. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
@@ -1,130 +0,0 @@
---
title: "General requests | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests"
fetched_at: "2026-02-26T10:38:11.585Z"
---
### Test connectivity[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests)
```
{ "id": "922bcc6e-9de8-440d-9e84-7c80933a8d0d", "method": "ping"}
```
Test connectivity to the WebSocket API.
**Note:** You can use regular WebSocket ping frames to test connectivity as well, WebSocket API will respond with pong frames as soon as possible. `ping` request along with `time` is a safe way to test request-response handling in your application.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "922bcc6e-9de8-440d-9e84-7c80933a8d0d", "status": 200, "result": {}, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 1 } ]}
```
### Check server time[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests)
```
{ "id": "187d3cb2-942d-484c-8271-4e2141bbadb1", "method": "time"}
```
Test connectivity to the WebSocket API and get the current server time.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "187d3cb2-942d-484c-8271-4e2141bbadb1", "status": 200, "result": { "serverTime": 1656400526260 }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 1 } ]}
```
### Exchange information[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests)
```
{ "id": "5494febb-d167-46a2-996d-70533eb4d976", "method": "exchangeInfo", "params": { "symbols": ["BNBBTC"] }}
```
Query current exchange trading rules, rate limits, and symbol information.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
`symbol`
STRING
NO
Describe a single symbol
`symbols`
ARRAY of STRING
Describe multiple symbols
`permissions`
ARRAY of STRING
Filter symbols by permissions
`showPermissionSets`
BOOLEAN
Controls whether the content of the `permissionSets` field is populated or not. Defaults to `true`.
`symbolStatus`
ENUM
Filters for symbols that have this `tradingStatus`.
Valid values: `TRADING`, `HALT`, `BREAK`
Cannot be used in combination with `symbol` or `symbols`
Notes:
- Only one of `symbol`, `symbols`, `permissions` parameters can be specified.
- Without parameters, `exchangeInfo` displays all symbols with `["SPOT, "MARGIN", "LEVERAGED"]` permissions.
- In order to list _all_ active symbols on the exchange, you need to explicitly request all permissions.
- `permissions` accepts either a list of permissions, or a single permission name. E.g. `"SPOT"`.
- [Available Permissions](https://developers.binance.com/docs/binance-spot-api-docs/testnet/enums)
**Examples of Symbol Permissions Interpretation from the Response:**
- `[["A","B"]]` means you may place an order if your account has either permission "A" **or** permission "B".
- `[["A"],["B"]]` means you can place an order if your account has permission "A" **and** permission "B".
- `[["A"],["B","C"]]` means you can place an order if your account has permission "A" **and** permission "B" or permission "C". (Inclusive or is applied here, not exclusive or, so your account may have both permission "B" and permission "C".)
**Data Source:** Memory
**Response:**
```
{ "id": "5494febb-d167-46a2-996d-70533eb4d976", "status": 200, "result": { "timezone": "UTC", "serverTime": 1655969291181, // Global rate limits. See "Rate limits" section. "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", // Rate limit type: REQUEST_WEIGHT, ORDERS, CONNECTIONS "interval": "MINUTE", // Rate limit interval: SECOND, MINUTE, DAY "intervalNum": 1, // Rate limit interval multiplier (i.e., "1 minute") "limit": 6000 // Rate limit per interval }, { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000 }, { "rateLimitType": "CONNECTIONS", "interval": "MINUTE", "intervalNum": 5, "limit": 300 } ], // Exchange filters are explained on the "Filters" page: // https://github.com/binance/binance-spot-api-docs/blob/master/filters.md // All exchange filters are optional. "exchangeFilters": [], "symbols": [ { "symbol": "BNBBTC", "status": "TRADING", "baseAsset": "BNB", "baseAssetPrecision": 8, "quoteAsset": "BTC", "quotePrecision": 8, "quoteAssetPrecision": 8, "baseCommissionPrecision": 8, "quoteCommissionPrecision": 8, "orderTypes": [ "LIMIT", "LIMIT_MAKER", "MARKET", "STOP_LOSS_LIMIT", "TAKE_PROFIT_LIMIT" ], "icebergAllowed": true, "ocoAllowed": true, "otoAllowed": true, "opoAllowed": true, "quoteOrderQtyMarketAllowed": true, "allowTrailingStop": true, "cancelReplaceAllowed": true, "amendAllowed": false, "pegInstructionsAllowed": true, "isSpotTradingAllowed": true, "isMarginTradingAllowed": true, // Symbol filters are explained on the "Filters" page: // https://github.com/binance/binance-spot-api-docs/blob/master/filters.md // All symbol filters are optional. "filters": [ { "filterType": "PRICE_FILTER", "minPrice": "0.00000100", "maxPrice": "100000.00000000", "tickSize": "0.00000100" }, { "filterType": "LOT_SIZE", "minQty": "0.00100000", "maxQty": "100000.00000000", "stepSize": "0.00100000" } ], "permissions": [], "permissionSets": [["SPOT", "MARGIN", "TRD_GRP_004"]], "defaultSelfTradePreventionMode": "NONE", "allowedSelfTradePreventionModes": ["NONE"] } ], // Optional field. Present only when SOR is available. // https://github.com/binance/binance-spot-api-docs/blob/master/faqs/sor_faq.md "sors": [ { "baseAsset": "BTC", "symbols": ["BTCUSDT", "BTCUSDC"] } ] }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 20 } ]}
```
- [Test connectivity](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests)
- [Check server time](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests)
- [Exchange information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/general-requests)
File diff suppressed because it is too large Load Diff
@@ -1,178 +0,0 @@
---
title: "Rate limits | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits"
fetched_at: "2026-02-26T10:38:11.792Z"
---
### Connection limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
There is a limit of **300 connections per attempt every 5 minutes**.
The connection is per **IP address**.
### General information on rate limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
- Current API rate limits can be queried using the [`exchangeInfo`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits) request.
- There are multiple rate limit types across multiple intervals.
- Responses can indicate current rate limit status in the optional `rateLimits` field.
- Requests fail with status `429` when unfilled order count or request rate limits are violated.
#### How to interpret rate limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
A response with rate limit status may look like this:
```
{ "id": "7069b743-f477-4ae3-81db-db9b8df085d2", "status": 200, "result": { "serverTime": 1656400526260 }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 70 } ]}
```
The `rateLimits` array describes all currently active rate limits affected by the request.
Name
Type
Mandatory
Description
`rateLimitType`
ENUM
YES
Rate limit type: `REQUEST_WEIGHT`, `ORDERS`
`interval`
ENUM
YES
Rate limit interval: `SECOND`, `MINUTE`, `HOUR`, `DAY`
`intervalNum`
INT
YES
Rate limit interval multiplier
`limit`
INT
YES
Request limit per interval
`count`
INT
YES
Current usage per interval
Rate limits are accounted by intervals.
For example, a `1 MINUTE` interval starts every minute. Request submitted at 00:01:23.456 counts towards the 00:01:00 minute's limit. Once the 00:02:00 minute starts, the count will reset to zero again.
Other intervals behave in a similar manner. For example, `1 DAY` rate limit resets at 00:00 UTC every day, and `10 SECOND` interval resets at 00, 10, 20... seconds of each minute.
APIs have multiple rate-limiting intervals. If you exhaust a shorter interval but the longer interval still allows requests, you will have to wait for the shorter interval to expire and reset. If you exhaust a longer interval, you will have to wait for that interval to reset, even if shorter rate limit count is zero.
#### How to show/hide rate limit information[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
`rateLimits` field is included with every response by default.
However, rate limit information can be quite bulky. If you are not interested in detailed rate limit status of every request, the `rateLimits` field can be omitted from responses to reduce their size.
- Optional `returnRateLimits` boolean parameter in request.
Use `returnRateLimits` parameter to control whether to include `rateLimits` fields in response to individual requests.
Default request and response:
```
{ "id": 1, "method": "time" }
```
```
{ "id": 1, "status": 200, "result": { "serverTime": 1656400526260 }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 70 } ]}
```
Request and response without rate limit status:
```
{ "id": 2, "method": "time", "params": { "returnRateLimits": false } }
```
```
{ "id": 2, "status": 200, "result": { "serverTime": 1656400527891 } }
```
- Optional `returnRateLimits` boolean parameter in connection URL.
If you wish to omit `rateLimits` from all responses by default, use `returnRateLimits` parameter in the query string instead:
```
wss://ws-api.binance.com:443/ws-api/v3?returnRateLimits=false
```
This will make all requests made through this connection behave as if you have passed `"returnRateLimits": false`.
If you _want_ to see rate limits for a particular request, you need to explicitly pass the `"returnRateLimits": true` parameter.
**Note:** Your requests are still rate limited if you hide the `rateLimits` field in responses.
### IP limits[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
- Every request has a certain **weight**, added to your limit as you perform requests.
- The heavier the request (e.g. querying data from multiple symbols), the more weight the request will cost.
- Connecting to WebSocket API costs 2 weight.
- Current weight usage is indicated by the `REQUEST_WEIGHT` rate limit type.
- Use the [`exchangeInfo`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits) request to keep track of the current weight limits.
- Weight is accumulated **per IP address** and is shared by all connections from that address.
- If you go over the weight limit, requests fail with status `429`.
- This status code indicates you should back off and stop spamming the API.
- Rate-limited responses include a `retryAfter` field, indicating when you can retry the request.
- **Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban and you will be disconnected.**
- Requests from a banned IP address fail with status `418`.
- `retryAfter` field indicates the timestamp when the ban will be lifted.
- IP bans are tracked and **scale in duration** for repeat offenders, **from 2 minutes to 3 days**.
Successful response indicating that in 1 minute you have used 70 weight out of your 6000 limit:
```
{ "id": "7069b743-f477-4ae3-81db-db9b8df085d2", "status": 200, "result": [], "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 70 } ]}
```
Failed response indicating that you are banned and the ban will last until epoch `1659146400000`:
```
{ "id": "fc93a61a-a192-4cf4-bb2a-a8f0f0c51e06", "status": 418, "error": { "code": -1003, "msg": "Way too much request weight used; IP banned until 1659146400000. Please use WebSocket Streams for live updates to avoid bans.", "data": { "serverTime": 1659142907531, "retryAfter": 1659146400000 } }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 2411 } ]}
```
### Unfilled Order Count[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
- Successfully placed orders update the `ORDERS` rate limit type.
- Rejected or unsuccessful orders might or might not update the `ORDERS` rate limit type.
- **Please note that if your orders are consistently filled by trades, you can continuously place orders on the API**. For more information, please see [Spot Unfilled Order Count Rules](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement).
- Use the [`account.rateLimits.orders`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/account-requests) request to keep track of how many orders you have placed within this interval.
- If you exceed this, requests fail with status `429`.
- This status code indicates you should back off and stop spamming the API.
- Responses that have a status `429` include a `retryAfter` field, indicating when you can retry the request.
- This is maintained **per account** and is shared by all API keys of the account.
Successful response indicating that you have placed 12 orders in 10 seconds, and 4043 orders in the past 24 hours:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "status": 200, "result": { "symbol": "BTCUSDT", "orderId": 12510053279, "orderListId": -1, "clientOrderId": "a097fe6304b20a7e4fc436", "transactTime": 1655716096505, "price": "0.10000000", "origQty": "10.00000000", "executedQty": "0.00000000", "origQuoteOrderQty": "0.000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1655716096505, "selfTradePreventionMode": "NONE" }, "rateLimits": [ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 12 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 4043 }, { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 321 } ]}
```
- [Connection limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
- [General information on rate limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
- [IP limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
- [Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/rate-limits)
@@ -1,54 +0,0 @@
---
title: "Request format | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-format"
fetched_at: "2026-02-26T10:38:11.797Z"
---
Requests must be sent as JSON in **text frames**, one request per frame.
Example of request:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "BUY", "type": "LIMIT", "price": "0.1", "quantity": "10", "timeInForce": "GTC", "timestamp": 1655716096498, "apiKey": "T59MTDLWlpRW16JVeZ2Nju5A5C98WkMm8CSzWC4oqynUlTm1zXOxyauT8LmwXEv9", "signature": "5942ad337e6779f2f4c62cd1c26dba71c91514400a24990a3e7f5edec9323f90" }}
```
Request fields:
Name
Type
Mandatory
Description
`id`
INT / STRING / `null`
YES
Arbitrary ID used to match responses to requests
`method`
STRING
YES
Request method name
`params`
OBJECT
NO
Request parameters. May be omitted if there are no parameters
- Request `id` is truly arbitrary. You can use UUIDs, sequential IDs, current timestamp, etc. The server does not interpret `id` in any way, simply echoing it back in the response.
You can freely reuse IDs within a session. However, be careful to not send more than one request at a time with the same ID, since otherwise it might be impossible to tell the responses apart.
- Request method names may be prefixed with explicit version: e.g., `"v3/order.place"`.
- The order of `params` is not significant.
@@ -1,589 +0,0 @@
---
title: "Request security | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security"
fetched_at: "2026-02-26T10:38:11.884Z"
---
- Each method has a security type indicating required API key permissions, shown next to the method name (e.g., [Place new order (TRADE)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)).
- If unspecified, the security type is `NONE`.
- Except for `NONE`, all methods with a security type are considered `SIGNED` requests (i.e. including a `signature`), except for [listenKey management](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security).
- Secure methods require a valid API key to be specified and authenticated.
- API keys can be created on the [SPOT Test Network](https://testnet.binance.vision/) upon logging in with your Github account.
- **Both API key and secret key are sensitive.** Never share them with anyone. If you notice unusual activity in your account, immediately revoke all the keys and contact Binance support.
- API keys can be configured to allow access only to certain types of secure methods.
- For example, you can have an API key with `TRADE` permission for trading, while using a separate API key with `USER_DATA` permission to monitor your order status.
- By default, an API key cannot `TRADE`. You need to enable trading in API Management first.
Security type
Description
`NONE`
Public market data
`TRADE`
Trading on the exchange, placing and canceling orders
`USER_DATA`
Private account information, such as order status and your trading history
`USER_STREAM`
Managing User Data Stream subscriptions
### SIGNED request security[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- `SIGNED` requests require an additional parameter: `signature`, authorizing the request.
#### Signature Case Sensitivity[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- **HMAC:** Signatures generated using HMAC are **not case-sensitive**. This means the signature string can be verified regardless of letter casing.
- **RSA:** Signatures generated using RSA are **case-sensitive**.
- **Ed25519:** Signatures generated using ED25519 are also **case-sensitive**
Please consult [SIGNED request example (HMAC)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security), [SIGNED request example (RSA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security), and [SIGNED request example (Ed25519)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security) on how to compute signature, depending on which API key type you are using.
### Timing security[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- `SIGNED` requests also require a `timestamp` parameter which should be the current timestamp either in milliseconds or microseconds. (See [General API Information](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security))
- An additional optional parameter, `recvWindow`, specifies for how long the request stays valid and may only be specified in milliseconds.
- `recvWindow` supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
- If `recvWindow` is not sent, **it defaults to 5000 milliseconds**.
- Maximum `recvWindow` is 60000 milliseconds.
- Request processing logic is as follows:
```
serverTime = getCurrentTime()if (timestamp < (serverTime + 1 second) && (serverTime - timestamp) <= recvWindow) { // begin processing request serverTime = getCurrentTime() if (serverTime - timestamp) <= recvWindow { // forward request to Matching Engine } else { // reject request } // finish processing 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!**
### SIGNED request example (HMAC)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
Here is a step-by-step guide on how to sign requests using an HMAC secret key.
Example API key and secret key:
Key
Value
`apiKey`
`vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A`
`secretKey`
`NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j`
**WARNING: DO NOT SHARE YOUR API KEY AND SECRET KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "------ FILL ME ------" }}
```
Example of a request with a symbol name containing non-ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "------ FILL ME ------" }}
```
As you can see, the `signature` parameter is currently missing.
**Step 1: Construct the signature payload**
Take all request `params` except `signature` and **sort them in alphabetical order by parameter name**:
For the first set of example parameters (ASCII only):
Parameter
Value
`apiKey`
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
`price`
52000.00
`quantity`
0.01000000
`recvWindow`
100
`side`
SELL
`symbol`
BTCUSDT
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
For the second set of example parameters (some non-ASCII characters):
Parameter
Value
`apiKey`
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
`price`
0.10000000
`quantity`
1.00000000
`recvWindow`
5000
`side`
BUY
`symbol`
123456
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
Format parameters as `parameter=value` pairs separated by `&`. Values need to be encoded in UTF-8.
For the first set of example parameters (ASCII only), the signature payload should look like this:
```
apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
```
apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
**Step 2: Compute the signature**
1. Use the `secretKey` of your API key as the signing key for the HMAC-SHA-256 algorithm.
2. Sign the UTF-8 bytes of the signature payload constructed in Step 1.
3. Encode the HMAC-SHA-256 output as a hex string.
Note that `apiKey`, `secretKey`, and the payload are **case-sensitive**, while the resulting signature value is case-insensitive.
You can cross-check your signature algorithm implementation with OpenSSL:
For the first set of example parameters (ASCII only):
```
$ echo -n 'apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -hex -sha256 -hmac 'NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j'aa1b5712c094bc4e57c05a1a5c1fd8d88dcd628338ea863fec7b88e59fe2db24
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n 'apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -hex -sha256 -hmac 'NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j'b33892ae8e687c939f4468c6268ddd4c40ac1af18ad19a064864c47bae0752cd
```
**Step 3: Add `signature` to request `params`**
Complete the request by adding the `signature` parameter with the signature string.
For the first set of example parameters (ASCII only):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "aa1b5712c094bc4e57c05a1a5c1fd8d88dcd628338ea863fec7b88e59fe2db24" }}
```
For the second set of example parameters (some non-ASCII characters):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "1.00000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "b33892ae8e687c939f4468c6268ddd4c40ac1af18ad19a064864c47bae0752cd" }}
```
### SIGNED request example (RSA)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
Here is a step-by-step guide on how to sign requests using an RSA private key.
Key
Value
`apiKey`
`CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ`
These examples assume the private key is stored in the file `test-rsa-prv.pem`.
**WARNING: DO NOT SHARE YOUR API KEY AND PRIVATE KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "------ FILL ME ------" }}
```
Example of a request with a symbol name containing non-ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "------ FILL ME ------" }}
```
**Step 1: Construct the signature payload**
Take all request `params` except `signature` and **sort them in alphabetical order by parameter name**:
For the first set of example parameters (ASCII only):
Parameter
Value
`apiKey`
CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ
`price`
52000.00
`quantity`
0.01000000
`recvWindow`
100
`side`
SELL
`symbol`
BTCUSDT
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
For the second set of example parameters (some non-ASCII characters):
Parameter
Value
`apiKey`
CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ
`price`
0.10000000
`quantity`
1.00000000
`recvWindow`
5000
`side`
BUY
`symbol`
123456
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
Format parameters as `parameter=value` pairs separated by `&`. Values need to be encoded in UTF-8.
For the first set of example parameters (ASCII only), the signature payload should look like this:
```
apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
```
apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
**Step 2: Compute the signature**
1. Sign the UTF-8 bytes of the signature payload constructed in Step 1 using the RSASSA-PKCS1-v1\_5 algorithm with SHA-256 hash function.
2. Encode the output in base64.
Note that `apiKey`, the payload, and the resulting `signature` are **case-sensitive**.
You can cross-check your signature algorithm implementation with OpenSSL:
For the first set of example parameters (ASCII only):
```
$ echo -n 'apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -sha256 -sign test-rsa-prv.pem \ | openssl enc -base64 -AOJJaf8C/3VGrU4ATTR4GiUDqL2FboSE1Qw7UnnoYNfXTXHubIl1iaePGuGyfct4NPu5oVEZCH4Q6ZStfB1w4ssgu0uiB/Bg+fBrRFfVgVaLKBdYHMvT+ljUJzqVaeoThG9oXlduiw8PbS9U8DYAbDvWN3jqZLo4Z2YJbyovyDAvDTr/oC0+vssLqP7NmlNb3fF3Bj7StmOwJvQJTbRAtzxK5PP7OQe+0mbW+D7RqVkUiSswR8qJFWTeSe4nXXNIdZdueYhF/Xf25L+KitJS5IHdIHcKfEw3MQzHFb2ZsGWkjDQwxkwr7Noi0Zaa+gFtxCuatGFm9dFIyx217pmSHtA==
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n 'apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -sha256 -sign test-rsa-prv.pem \ | openssl enc -base64 -AF3o/79Ttvl2cVYGPfBOF3oEOcm5QcYmTYWpdVIrKve5u+8paMNDAdUE+teqMxFM9HcquetGcfuFpLYtsQames5bDx/tskGM76TWW8HaM+6tuSYBSFLrKqChfA9hQGLYGjAiflf1YBnDhY+7vNbJFusUborNOloOj+ufzP5q42PvI3H0uNy3W5V3pyfXpDGCBtfCYYr9NAqA4d+AQfyllL/zkO9h9JSdozN49t0/hWGoD2dWgSO0Je6MytKEvD4DQXGeqNlBTB6tUXcWnRW+FcaKZ4KYqnxCtb1u8rFXUYgFykr2CbcJLSmw6ydEJ3EZ/NaZopRr+cU0W2m0HZ3qucw==
```
**Step 3: Add `signature` to request `params`**
Complete the request by adding the `signature` parameter with the signature string.
For the first set of example parameters (ASCII only):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "newOrderRespType": "ACK", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "OJJaf8C/3VGrU4ATTR4GiUDqL2FboSE1Qw7UnnoYNfXTXHubIl1iaePGuGyfct4NPu5oVEZCH4Q6ZStfB1w4ssgu0uiB/Bg+fBrRFfVgVaLKBdYHMvT+ljUJzqVaeoThG9oXlduiw8PbS9U8DYAbDvWN3jqZLo4Z2YJbyovyDAvDTr/oC0+vssLqP7NmlNb3fF3Bj7StmOwJvQJTbRAtzxK5PP7OQe+0mbW+D7RqVkUiSswR8qJFWTeSe4nXXNIdZdueYhF/Xf25L+KitJS5IHdIHcKfEw3MQzHFb2ZsGWkjDQwxkwr7Noi0Zaa+gFtxCuatGFm9dFIyx217pmSHtA==" }}
```
For the second set of example parameters (some non-ASCII characters):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "1.00000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "F3o/79Ttvl2cVYGPfBOF3oEOcm5QcYmTYWpdVIrKve5u+8paMNDAdUE+teqMxFM9HcquetGcfuFpLYtsQames5bDx/tskGM76TWW8HaM+6tuSYBSFLrKqChfA9hQGLYGjAiflf1YBnDhY+7vNbJFusUborNOloOj+ufzP5q42PvI3H0uNy3W5V3pyfXpDGCBtfCYYr9NAqA4d+AQfyllL/zkO9h9JSdozN49t0/hWGoD2dWgSO0Je6MytKEvD4DQXGeqNlBTB6tUXcWnRW+FcaKZ4KYqnxCtb1u8rFXUYgFykr2CbcJLSmw6ydEJ3EZ/NaZopRr+cU0W2m0HZ3qucw==" }}
```
### SIGNED Request Example (Ed25519)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
**Note: It is highly recommended to use Ed25519 API keys as they will provide the best performance and security out of all supported key types.**
Here is a step-by-step guide on how to sign requests using an Ed25519 private key.
Key
Value
`apiKey`
`4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO`
These examples assume the private key is stored in the file `test-ed25519-prv.pem`.
**WARNING: DO NOT SHARE YOUR API KEY AND PRIVATE KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "------ FILL ME ------" }}
```
Example of a request with a symbol name containing non-ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "------ FILL ME ------" }}
```
**Step 1: Construct the signature payload**
Take all request `params` except `signature` and **sort them in alphabetical order by parameter name**:
For the first set of example parameters (ASCII only):
Parameter
Value
`apiKey`
4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO
`price`
52000.00
`quantity`
0.01000000
`recvWindow`
100
`side`
SELL
`symbol`
BTCUSDT
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
For the second set of example parameters (some non-ASCII characters):
Parameter
Value
`apiKey`
4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO
`price`
0.20000000
`quantity`
1.00000000
`recvWindow`
5000
`side`
SELL
`symbol`
123456
`timeInForce`
GTC
`timestamp`
1668481559918
`type`
LIMIT
Format parameters as `parameter=value` pairs separated by `&`. Values need to be encoded in UTF-8.
For the first set of example parameters (ASCII only), the signature payload should look like this:
```
apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
```
apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
**Step 2: Compute the signature**
1. Sign the UTF-8 bytes of your signature payload constructed in Step 1 using the Ed25519 private key.
2. Encode the output in base64.
Note that `apiKey`, the payload, and the resulting `signature` are **case-sensitive**.
You can cross-check your signature algorithm implementation with OpenSSL:
For the first set of example parameters (ASCII only):
```
echo -n "apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT" \ | openssl dgst -sign ./test-ed25519-prv.pem \ | openssl enc -base64 -AEocljwPl29jDxWYaaRaOo4pJ9wEblFbklJvPugNscLLuKd5vHM2grWjn1z+rY0aJ7r/44enxHL6mOAJuJ1kqCg==
```
For the second set of example parameters (some non-ASCII characters):
```
echo -n "apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT" \ | openssl dgst -sign ./test-ed25519-prv.pem \ | openssl enc -base64 -AdtNHJeyKry+cNjiGv+sv5kynO9S40tf8k7D5CfAEQAp0s2scunZj+ovJdz2OgW8XhkB9G3/HmASkA9uY9eyFCA==
```
**Step 3: Add the signature to request `params`**
For the first set of example parameters (ASCII only):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "newOrderRespType": "ACK", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "EocljwPl29jDxWYaaRaOo4pJ9wEblFbklJvPugNscLLuKd5vHM2grWjn1z+rY0aJ7r/44enxHL6mOAJuJ1kqCg==" }}
```
For the second set of example parameters (some non-ASCII characters):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "1.00000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "dtNHJeyKry+cNjiGv+sv5kynO9S40tf8k7D5CfAEQAp0s2scunZj+ovJdz2OgW8XhkB9G3/HmASkA9uY9eyFCA==" }}
```
Here is a sample Python script performing all the steps above:
```
#!/usr/bin/env python3import base64import timeimport jsonfrom cryptography.hazmat.primitives.serialization import load_pem_private_keyfrom websocket import create_connection# Set up authenticationAPI_KEY='put your own API Key here'PRIVATE_KEY_PATH='test-prv-key.pem'# Load the private key.# In this example the key is expected to be stored without encryption,# but we recommend using a strong password for improved security.with open(PRIVATE_KEY_PATH, 'rb') as f: private_key = load_pem_private_key(data=f.read(), password=None)# Set up the request parametersparams = { 'apiKey': API_KEY, 'symbol': '123456', 'side': 'SELL', 'type': 'LIMIT', 'timeInForce': 'GTC', 'quantity': '1.0000000', 'price': '0.10000000', 'recvWindow': 5000}# Timestamp the requesttimestamp = int(time.time() * 1000) # UNIX timestamp in millisecondsparams['timestamp'] = timestamp# Sort parameters alphabetically by nameparams = dict(sorted(params.items()))# Compute the signature payloadpayload = '&'.join([f"{k}={v}" for k,v in params.items()]) # no percent encoding here!# Sign the requestsignature = base64.b64encode(private_key.sign(payload.encode('UTF-8')))params['signature'] = signature.decode('ASCII')# Send the requestrequest = { 'id': 'my_new_order', 'method': 'order.place', 'params': params}ws = create_connection("wss://ws-api.testnet.binance.vision/ws-api/v3")ws.send(json.dumps(request))result = ws.recv()ws.close()print(result)
```
- [SIGNED request security](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- [Timing security](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- [SIGNED request example (HMAC)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- [SIGNED request example (RSA)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
- [SIGNED Request Example (Ed25519)](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/request-security)
@@ -1,86 +0,0 @@
---
title: "Response format | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/response-format"
fetched_at: "2026-02-26T10:38:12.057Z"
---
Responses are returned as JSON in **text frames**, one response per frame.
Example of successful response:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "status": 200, "result": { "symbol": "BTCUSDT", "orderId": 12510053279, "orderListId": -1, "clientOrderId": "a097fe6304b20a7e4fc436", "transactTime": 1655716096505, "price": "0.10000000", "origQty": "10.00000000", "executedQty": "0.00000000", "origQuoteOrderQty": "0.000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1655716096505, "selfTradePreventionMode": "NONE" }, "rateLimits": [ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 12 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 4043 }, { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 321 } ]}
```
Example of failed response:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "status": 400, "error": { "code": -2010, "msg": "Account has insufficient balance for requested action." }, "rateLimits": [ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 13 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 4044 }, { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 322 } ]}
```
Response fields:
Name
Type
Mandatory
Description
`id`
INT / STRING / `null`
YES
Same as in the original request
`status`
INT
YES
Response status. See [Status codes](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/response-format)
`result`
OBJECT / ARRAY
YES
Response content. Present if request succeeded
`error`
OBJECT
Error description. Present if request failed
`rateLimits`
ARRAY
NO
Rate limiting status. See [Rate limits](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/response-format)
### Status codes[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/response-format)
Status codes in the `status` field are the same as in HTTP.
Here are some common status codes that you might encounter:
- `200` indicates a successful response.
- `4XX` status codes indicate invalid requests; the issue is on your side.
- `400` your request failed, see `error` for the reason.
- `403` you have been blocked by the Web Application Firewall. This can indicate a rate limit violation or a security block. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
- `409` your request partially failed but also partially succeeded, see `error` for details.
- `418` you have been auto-banned for repeated violation of rate limits.
- `429` you have exceeded API request rate limit, please slow down.
- `5XX` status codes indicate internal errors; the issue is on Binance's side.
- **Important:** If a response contains 5xx status code, it **does not** necessarily mean that your request has failed. Execution status is _unknown_ and the request might have actually succeeded. Please use query methods to confirm the status. You might also want to establish a new WebSocket connection for that.
See [Error codes for Binance](https://developers.binance.com/docs/binance-spot-api-docs/testnet/errors) for a list of error codes and messages.
- [Status codes](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/response-format)
@@ -1,37 +0,0 @@
---
title: "Session Authentication | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication"
fetched_at: "2026-02-26T10:38:12.191Z"
---
**Note:** Only _Ed25519_ keys are supported for this feature.
If you do not want to specify `apiKey` and `signature` in each individual request, you can authenticate your API key for the active WebSocket session.
Once authenticated, you no longer have to specify `apiKey` and `signature` for those requests that need them. Requests will be performed on behalf of the account owning the authenticated API key.
**Note:** You still have to specify the `timestamp` parameter for `SIGNED` requests.
### Authenticate after connection[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication)
You can authenticate an already established connection using session authentication requests:
- [`session.logon`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication) authenticate, or change the API key associated with the connection
- [`session.status`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication) check connection status and the current API key
- [`session.logout`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication) forget the API key associated with the connection
**Regarding API key revocation:**
If during an active session the API key becomes invalid for _any reason_ (e.g. IP address is not whitelisted, API key was deleted, API key doesn't have correct permissions, etc), after the next request the session will be revoked with the following error message:
```
{ "id": null, "status": 401, "error": { "code": -2015, "msg": "Invalid API-key, IP, or permissions for action." }}
```
### Authorize _ad hoc_ requests[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication)
Only one API key can be authenticated with the WebSocket connection. The authenticated API key is used by default for requests that require an `apiKey` parameter. However, you can always specify the `apiKey` and `signature` explicitly for individual requests, overriding the authenticated API key and using a different one to authorize a specific request.
For example, you might want to authenticate your `USER_DATA` key to be used by default, but specify the `TRADE` key with an explicit signature when placing orders.
- [Authenticate after connection](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication)
- [Authorize _ad hoc_ requests](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/session-authentication)
File diff suppressed because it is too large Load Diff
@@ -1,164 +0,0 @@
---
title: "User Data Stream requests | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests"
fetched_at: "2026-02-26T10:38:12.155Z"
---
### User Data Stream subscription[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests)
**General information:**
- [User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream) subscriptions allow you to receive all the events related to a given account on a WebSocket connection.
- There are 2 ways to start a subscription:
- If you have an authenticated session, then you can subscribe to events for that authenticated account using [`userDataStream.subscribe`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests).
- In any session, authenticated or not, you can subscribe to events for one or more accounts for which you can provide an API Key signature, using [`userDataStream.subscribe.signature`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests).
- You can have only one active subscription for a given account on a given connection.
- Subscriptions are identified by a `subscriptionId` which is returned when starting the subscription. That `subscriptionId` allows you to map the events you receive to a given subscription.
- All active subscriptions for a session can be found using [`session.subscriptions`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests).
- Limits
- A single session supports **up to 1,000 active subscriptions** simultaneously.
- Attempting to start a new subscription beyond this limit will result in an error.
- If your accounts are very active, we suggest not opening too many subscriptions at once, in order to not overload your connection.
- A single session can handle a maximum of **65,535 total subscriptions** over its lifetime.
- If this limit is reached, you will receive an error and must re-establish a new connection to be able to start new subscriptions.
- To verify the status of User Data Stream subscriptions, check the `userDataStream` field in [`session.status`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests):
- `null` - User Data Stream subscriptions are **not available** on this WebSocket API.
- `true` - There is at **least one subscription active** in this session.
- `false` - There are **no active subscriptions** in this session.
#### Subscribe to User Data Stream (USER\_STREAM)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests)
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "method": "userDataStream.subscribe"}
```
Subscribe to the User Data Stream in the current WebSocket connection.
**Notes:**
- This method requires an authenticated WebSocket connection using Ed25519 keys. Please refer to [`session.logon`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests).
- To check the subscription status, use [`session.status`](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/authentication-requests), see the `userDataStream` flag indicating you have have an active subscription.
- User Data Stream events are available in both JSON and [SBE](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) sessions.
- Please refer to [User Data Streams](https://developers.binance.com/docs/binance-spot-api-docs/testnet/user-data-stream) for the event format details.
- For SBE, only SBE schema 2:1 or later is supported.
**Weight**: 2
**Parameters**: NONE
**Response**:
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "status": 200, "result": { "subscriptionId": 0 }}
```
#### Unsubscribe from User Data Stream[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests)
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "method": "userDataStream.unsubscribe"}
```
Stop listening to the User Data Stream in the current WebSocket connection.
Note that `session.logout` will only close the subscription created with `userDataStream.subscribe` but not subscriptions opened with `userDataStream.subscribe.signature`.
**Weight**: 2
**Parameters**:
Name
Type
Mandatory
Description
`subscriptionId`
INT
No
When called with no parameter, this will close all subscriptions.
When called with the `subscriptionId` parameter, this will attempt to close the subscription with that subscription id, if it exists.
**Response**:
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "status": 200, "result": {}}
```
#### Listing all subscriptions[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests)
```
{ "id": "d3df5a22-88ea-4fe0-9f4e-0fcea5d418b7", "method": "session.subscriptions", "params": {}}
```
**Note:**
- Users are expected to track on their side which subscription corresponds to which account.
**Weight**: 2
**Data Source**: Memory
**Response**:
```
{ "id": "d3df5a22-88ea-4fe0-9f4e-0fcea5d418b7", "status": 200, "result": [ { "subscriptionId": 0 }, { "subscriptionId": 1 } ]}
```
#### Subscribe to User Data Stream through signature subscription (USER\_STREAM)[](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests)
```
{ "id": "d3df8a22-98ea-4fe0-9f4e-0fcea5d418b7", "method": "userDataStream.subscribe.signature", "params": { "apiKey": "mjcKCrJzTU6TChLsnPmgnQJJMR616J4yWvdZWDUeXkk6vL6dLyS7rcVOQlADlVjA", "timestamp": 1747385641636, "signature": "yN1vWpXb+qoZ3/dGiFs9vmpNdV7e3FxkA+BstzbezDKwObcijvk/CVkWxIwMCtCJbP270R0OempYwEpS6rDZCQ==" }}
```
**Weight:** 2
**Parameters**:
Name
Type
Mandatory
Description
`apiKey`
STRING
Yes
`timestamp`
LONG
Yes
`signature`
STRING
Yes
`recvWindow`
DECIMAL
No
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
**Data Source:** Memory
**Response:**
```
{ "id": "d3df8a22-98ea-4fe0-9f4e-0fcea5d418b7", "status": 200, "result": { "subscriptionId": 0 }}
```
- [User Data Stream subscription](https://developers.binance.com/docs/binance-spot-api-docs/testnet/websocket-api/user-data-stream-requests)
@@ -1,293 +0,0 @@
---
title: "User Data Stream | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream"
fetched_at: "2026-02-26T10:38:12.317Z"
---
# User Data Streams for Binance
## General information[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- Subscribe via the [WebSocket API](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests) using an API Key.
- Both [SBE](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) and JSON output are supported.
- Account events are pushed in **real-time**.
- All timestamps in JSON payloads are in **milliseconds by default**.
- Events may contain non-ASCII characters encoded in UTF-8 if you own or trade any assets or symbols whose names contain non-ASCII characters.
## User Data Stream Events[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
### Account Update[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
`outboundAccountPosition` is sent any time an account balance has changed and contains the assets that were possibly changed by the event that generated the balance change.
```
{ "subscriptionId": 0, "event": { "e": "outboundAccountPosition", // Event type "E": 1564034571105, // Event Time "u": 1564034571073, // Time of last account update // Balances Array "B": [ { "a": "ETH", // Asset "f": "10000.000000", // Free "l": "0.000000" // Locked } ] }}
```
### Balance Update[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
Balance Update occurs during the following:
- Deposits or withdrawals from the account
- Transfer of funds between accounts (e.g. Spot to Margin)
**Payload**
```
{ "subscriptionId": 0, "event": { "e": "balanceUpdate", // Event Type "E": 1573200697110, // Event Time "a": "BTC", // Asset "d": "100.00000000", // Balance Delta "T": 1573200697068 // Clear Time }}
```
### Order Update[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
Orders are updated with the `executionReport` event.
**Payload:**
```
{ "subscriptionId": 0, "event": { "e": "executionReport", // Event type "E": 1499405658658, // Event time "s": "ETHBTC", // Symbol "c": "mUvoqJxFIILMdfAW5iGSOW", // Client order ID "S": "BUY", // Side "o": "LIMIT", // Order type "f": "GTC", // Time in force "q": "1.00000000", // Order quantity "p": "0.10264410", // Order price "P": "0.00000000", // Stop price "F": "0.00000000", // Iceberg quantity "g": -1, // OrderListId "C": "", // Original client order ID; This is the ID of the order being canceled "x": "NEW", // Current execution type "X": "NEW", // Current order status "r": "NONE", // Order reject reason; Please see Order Reject Reason (below) for more information. "i": 4293153, // Order ID "l": "0.00000000", // Last executed quantity "z": "0.00000000", // Cumulative filled quantity "L": "0.00000000", // Last executed price "n": "0", // Commission amount "N": null, // Commission asset "T": 1499405658657, // Transaction time "t": -1, // Trade ID "v": 3, // Prevented Match Id; This is only visible if the order expired due to STP "I": 8641984, // Execution Id "w": true, // Is the order on the book? "m": false, // Is this trade the maker side? "M": false, // Ignore "O": 1499405658657, // Order creation time "Z": "0.00000000", // Cumulative quote asset transacted quantity "Y": "0.00000000", // Last quote asset transacted quantity (i.e. lastPrice * lastQty) "Q": "0.00000000", // Quote Order Quantity "W": 1499405658657, // Working Time; This is only visible if the order has been placed on the book. "V": "NONE" // SelfTradePreventionMode }}
```
**Note:** Average price can be found by doing `Z` divided by `z`.
#### Conditional Fields in Execution Report[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
These are fields that appear in the payload only if certain conditions are met.
For additional information on these parameters, please refer to the [Spot Glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary).
Field
Name
Description
Examples
`d`
Trailing Delta
Appears only for trailing stop orders.
`"d": 4`
`D`
Trailing Time
`"D": 1668680518494`
`j`
Strategy Id
Appears only if the `strategyId` parameter was provided upon order placement.
`"j": 1`
`J`
Strategy Type
Appears only if the `strategyType` parameter was provided upon order placement.
`"J": 1000000`
`v`
Prevented Match Id
Appears only for orders that expired due to STP.
`"v": 3`
`A`
Prevented Quantity
`"A":"3.000000"`
`B`
Last Prevented Quantity
`"B":"3.000000"`
`u`
Trade Group Id
`"u":1`
`U`
Counter Order Id
`"U":37`
`Cs`
Counter Symbol
`"Cs": "BTCUSDT"`
`pl`
Prevented Execution Quantity
`"pl":"2.123456"`
`pL`
Prevented Execution Price
`"pL":"0.10000001"`
`pY`
Prevented Execution Quote Qty
`"pY":"0.21234562"`
`W`
Working Time
Appears when the order is working on the book
`"W": 1668683798379`
`b`
Match Type
Appears for orders that have allocations
`"b":"ONE_PARTY_TRADE_REPORT"`
`a`
Allocation ID
`"a":1234`
`k`
Working Floor
Appears for orders that potentially have allocations
`"k":"SOR"`
`uS`
UsedSor
Appears for orders that used SOR
`"uS":true`
`gP`
Pegged Price Type
Appears only for Pegged Orders
`"gP": "PRIMARY_PEG"`
`gOT`
Pegged offset Type
`"gOT": "PRICE_LEVEL"`
`gOV`
Pegged Offset Value
`"gOV": 5`
`gp`
Pegged Price
`"gp": "1.00000000"`
#### Order Reject Reason[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
For additional details, look up the Error Message in the [Errors](https://developers.binance.com/docs/binance-spot-api-docs/errors) documentation.
Rejection Reason (`r`)
Error Message
`NONE`
N/A (i.e. The order was not rejected.)
`INSUFFICIENT_BALANCES`
"Account has insufficient balance for requested action."
`STOP_PRICE_WOULD_TRIGGER_IMMEDIATELY`
"Order would trigger immediately."
`WOULD_MATCH_IMMEDIATELY`
"Order would immediately match and take."
`OCO_BAD_PRICES`
"The relationship of the prices for the orders is not correct."
If the order is an order list, an event named `ListStatus` will be sent in addition to the `executionReport` event.
**Payload**
```
{ "subscriptionId": 0, "event": { "e": "listStatus", // Event Type "E": 1564035303637, // Event Time "s": "ETHBTC", // Symbol "g": 2, // OrderListId "c": "OCO", // Contingency Type "l": "EXEC_STARTED", // List Status Type "L": "EXECUTING", // List Order Status "r": "NONE", // List Reject Reason "C": "F4QN4G8DlFATFlIUQ0cjdD", // List Client Order ID "T": 1564035303625, // Transaction Time // An array of objects "O": [ { "s": "ETHBTC", // Symbol "i": 17, // OrderId "c": "AJYsMjErWJesZvqlJCTUgL" // ClientOrderId }, { "s": "ETHBTC", "i": 18, "c": "bfYPSQdLoqAJeNrOr9adzq" } ] }}
```
**Execution types:**
- `NEW` - The order has been accepted into the engine.
- `CANCELED` - The order has been canceled by the user.
- `REPLACED` - The order has been amended.
- `REJECTED` - The order has been rejected and was not processed (e.g. Cancel Replace Orders wherein the new order placement is rejected but the request to cancel request succeeds.)
- `TRADE` - Part of the order or all of the order's quantity has filled.
- `EXPIRED` - The order was canceled according to the order type's rules (e.g. LIMIT FOK orders with no fill, LIMIT IOC or MARKET orders that partially fill) or by the exchange, (e.g. orders canceled during liquidation, orders canceled during maintenance).
- `TRADE_PREVENTION` - The order has expired due to STP.
Check the [Enums page](https://developers.binance.com/docs/binance-spot-api-docs/enums) for more relevant enum definitions.
## Event Stream Terminated[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
`eventStreamTerminated` is sent when:
- [A listen token subscription](https://developers.binance.com/docs/margin_trading/trade-data-stream/Listen-Token-Websocket-API) expires due to token expiration.
- A [logon subscription](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests) ends after sending [`session.logout`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests) method.
- The subscription is stopped via the [`userDataStream.unsubscribe`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests) method.
**Payload:**
```
{ "subscriptionId": 0, "event": { "e": "eventStreamTerminated", // Event Type "E": 1728973001334 // Event Time }}
```
## External Lock Update[](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
`externalLockUpdate` is sent when part of your spot wallet balance is locked/unlocked by an external system, for example when used as margin collateral.
**Payload:**
```
{ "subscriptionId": 0, "event": { "e": "externalLockUpdate", // Event Type "E": 1581557507324, // Event Time "a": "NEO", // Asset "d": "10.00000000", // Delta "T": 1581557507268 // Transaction Time }}
```
- [General information](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- [User Data Stream Events](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- [Account Update](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- [Balance Update](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- [Order Update](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- [Event Stream Terminated](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
- [External Lock Update](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
@@ -1,2 +0,0 @@
URL: https://developers.binance.com/docs/binance-spot-api-docs/web-socket-api.md
Error: 404
@@ -1,434 +0,0 @@
---
title: "WebSocket Streams | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams"
fetched_at: "2026-02-26T10:38:12.473Z"
---
# WebSocket Streams for Binance
## General WSS information[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- The base endpoint is: **wss://stream.binance.com:9443** or **wss://stream.binance.com:443**.
- 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>}**
- All symbols for streams are **lowercase**
- A single connection to **stream.binance.com** is only valid for 24 hours; expect to be disconnected at the 24 hour mark
- The WebSocket server will send a `ping frame` every 20 seconds.
- If the WebSocket server does not receive a `pong frame` back from the connection within a minute the connection will be disconnected.
- When you receive a ping, you must send a pong with a copy of ping's payload as soon as possible.
- Unsolicited `pong frames` are allowed, but will not prevent disconnection. **It is recommended that the payload for these pong frames are empty.**
- The base endpoint **wss://data-stream.binance.vision** can be subscribed to receive **only** market data messages.
User data stream is **NOT** available from this URL.
- All time and timestamp related fields are **milliseconds by default**. To receive the information in microseconds, please add the parameter `timeUnit=MICROSECOND or timeUnit=microsecond` in the URL.
- For example: `/stream?streams=btcusdt@trade&timeUnit=MICROSECOND`
- If your request contains a symbol name containing non-ASCII characters, then the stream events may contain non-ASCII characters encoded in UTF-8.
- \[All Market Mini Tickers Stream\](#all-market-mini-tickers-stream and [All Market Rolling Window Statistics Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams) events may contain non-ASCII characters encoded in UTF-8.
## WebSocket Limits[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- WebSocket connections have a limit of 5 incoming messages per second. A message is considered:
- A PING frame
- A PONG frame
- A JSON controlled 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.
- There is a limit of **300 connections per attempt every 5 minutes per IP**.
## Live Subscribing/Unsubscribing to streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-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` is used as an identifier to uniquely identify the messages going back and forth. The following formats are accepted:
- 64-bit signed integer
- alphanumeric strings; max length 36
- `null`
- 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[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- Request
```
{ "method": "SUBSCRIBE", "params": ["btcusdt@aggTrade", "btcusdt@depth"], "id": 1}
```
- Response
```
{ "result": null, "id": 1}
```
### Unsubscribe to a stream[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- Request
```
{ "method": "UNSUBSCRIBE", "params": ["btcusdt@depth"], "id": 312}
```
- Response
```
{ "result": null, "id": 312}
```
### Listing Subscriptions[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- Request
```
{ "method": "LIST_SUBSCRIPTIONS", "id": 3}
```
- Response
```
{ "result": ["btcusdt@aggTrade"], "id": 3}
```
### Setting Properties[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Currently, the only property that can be set is whether `combined` stream payloads are enabled or 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[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- Request
```
{ "method": "GET_PROPERTY", "params": ["combined"], "id": 2}
```
- Response
```
{ "result": true, // Indicates that combined is set to true. "id": 2}
```
### Error Messages[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Error Message
Description
{"code": 0, "msg": "Unknown property","id": %s}
Parameter used in the `SET_PROPERTY` or `GET_PROPERTY` was invalid
{"code": 1, "msg": "Invalid value type: expected Boolean"}
Value should only be `true` or `false`
{"code": 2, "msg": "Invalid request: property name must be a string"}
Property name provided was invalid
{"code": 2, "msg": "Invalid request: request ID must be an unsigned integer"}
Parameter `id` had to be provided or the value provided in the `id` parameter is an unsupported type
{"code": 2, "msg": "Invalid request: unknown variant %s, expected one of `SUBSCRIBE`, `UNSUBSCRIBE`, `LIST_SUBSCRIPTIONS`, `SET_PROPERTY`, `GET_PROPERTY` at line 1 column 28"}
Possible typo in the provided method or provided method was neither of the expected values
{"code": 2, "msg": "Invalid request: too many parameters"}
Unnecessary parameters provided in the data
{"code": 2, "msg": "Invalid request: property name must be a string"}
Property name was not provided
{"code": 2, "msg": "Invalid request: missing field `method` at line 1 column 73"}
`method` was not provided in the data
{"code":3,"msg":"Invalid JSON: expected value at line %s column %s"}
JSON data sent has incorrect syntax.
# Detailed Stream information
## Aggregate Trade Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-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:**
```
{ "e": "aggTrade", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "a": 12345, // Aggregate trade ID "p": "0.001", // Price "q": "100", // Quantity "f": 100, // First trade ID "l": 105, // Last trade ID "T": 1672515782136, // Trade time "m": true, // Is the buyer the market maker? "M": true // Ignore}
```
## Trade Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-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:**
```
{ "e": "trade", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "t": 12345, // Trade ID "p": "0.001", // Price "q": "100", // Quantity "T": 1672515782136, // Trade time "m": true, // Is the buyer the market maker? "M": true // Ignore}
```
## Kline/Candlestick Streams for UTC[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
The Kline/Candlestick Stream push updates to the current klines/candlestick every second in `UTC+0` timezone
**Kline/Candlestick chart intervals:**
s-> seconds; m -> minutes; h -> hours; d -> days; w -> weeks; M -> months
- 1s
- 1m
- 3m
- 5m
- 15m
- 30m
- 1h
- 2h
- 4h
- 6h
- 8h
- 12h
- 1d
- 3d
- 1w
- 1M
**Stream Name:** <symbol>@kline\_<interval>
**Update Speed:** 1000ms for `1s`, 2000ms for the other intervals
**Payload:**
```
{ "e": "kline", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "k": { "t": 1672515780000, // Kline start time "T": 1672515839999, // Kline close time "s": "BNBBTC", // Symbol "i": "1m", // Interval "f": 100, // First trade ID "L": 200, // Last trade ID "o": "0.0010", // Open price "c": "0.0020", // Close price "h": "0.0025", // High price "l": "0.0015", // Low price "v": "1000", // Base asset volume "n": 100, // Number of trades "x": false, // Is this kline closed? "q": "1.0000", // Quote asset volume "V": "500", // Taker buy base asset volume "Q": "0.500", // Taker buy quote asset volume "B": "123456" // Ignore }}
```
## Kline/Candlestick Streams with timezone offset[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
The Kline/Candlestick Stream push updates to the current klines/candlestick every second in `UTC+8` timezone
**Kline/Candlestick chart intervals:**
Supported intervals: See [`Kline/Candlestick chart intervals`](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
**UTC+8 timezone offset:**
- Kline intervals open and close in the `UTC+8` timezone. For example the `1d` klines will open at the beginning of the `UTC+8` day, and close at the end of the `UTC+8` day.
- Note that `E` (event time), `t` (start time) and `T` (close time) in the payload are Unix timestamps, which are always interpreted in UTC.
**Stream Name:** <symbol>@kline\_<interval>@+08:00
**Update Speed:** 1000ms for `1s`, 2000ms for the other intervals
**Payload:**
```
{ "e": "kline", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "k": { "t": 1672515780000, // Kline start time "T": 1672515839999, // Kline close time "s": "BNBBTC", // Symbol "i": "1m", // Interval "f": 100, // First trade ID "L": 200, // Last trade ID "o": "0.0010", // Open price "c": "0.0020", // Close price "h": "0.0025", // High price "l": "0.0015", // Low price "v": "1000", // Base asset volume "n": 100, // Number of trades "x": false, // Is this kline closed? "q": "1.0000", // Quote asset volume "V": "500", // Taker buy base asset volume "Q": "0.500", // Taker buy quote asset volume "B": "123456" // Ignore }}
```
## Individual Symbol Mini Ticker Stream[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
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:**
```
{ "e": "24hrMiniTicker", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "c": "0.0025", // Close price "o": "0.0010", // Open price "h": "0.0025", // High price "l": "0.0010", // Low price "v": "10000", // Total traded base asset volume "q": "18" // Total traded quote asset volume}
```
## All Market Mini Tickers Stream[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
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:**
```
[ { // Same as <symbol>@miniTicker payload }]
```
## Individual Symbol Ticker Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
24hr rolling window ticker statistics for a single symbol. These are NOT the statistics of the UTC day, but a 24hr rolling window for the previous 24hrs.
**Stream Name:** <symbol>@ticker
**Update Speed:** 1000ms
**Payload:**
```
{ "e": "24hrTicker", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "p": "0.0015", // Price change "P": "250.00", // Price change percent "w": "0.0018", // Weighted average price "x": "0.0009", // First trade(F)-1 price (first trade before the 24hr rolling window) "c": "0.0025", // Last price "Q": "10", // Last quantity "b": "0.0024", // Best bid price "B": "10", // Best bid quantity "a": "0.0026", // Best ask price "A": "100", // Best ask quantity "o": "0.0010", // Open price "h": "0.0025", // High price "l": "0.0010", // Low price "v": "10000", // Total traded base asset volume "q": "18", // Total traded quote asset volume "O": 0, // Statistics open time "C": 86400000, // Statistics close time "F": 0, // First trade ID "L": 18150, // Last trade Id "n": 18151 // Total number of trades}
```
## Individual Symbol Rolling Window Statistics Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Rolling window ticker statistics for a single symbol, computed over multiple windows.
**Stream Name:** <symbol>@ticker\_<window\_size>
**Window Sizes:** 1h,4h,1d
**Update Speed:** 1000ms
**Note**: This stream is different from the <symbol>@ticker stream. The open time `"O"` always starts on a minute, while the closing time `"C"` is the current time of the update. As such, the effective window might be up to 59999ms wider than <window\_size>.
**Payload:**
```
{ "e": "1hTicker", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "p": "0.0015", // Price change "P": "250.00", // Price change percent "o": "0.0010", // Open price "h": "0.0025", // High price "l": "0.0010", // Low price "c": "0.0025", // Last price "w": "0.0018", // Weighted average price "v": "10000", // Total traded base asset volume "q": "18", // Total traded quote asset volume "O": 0, // Statistics open time "C": 1675216573749, // Statistics close time "F": 0, // First trade ID "L": 18150, // Last trade Id "n": 18151 // Total number of trades}
```
## All Market Rolling Window Statistics Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Rolling window ticker statistics for all market symbols, computed over multiple windows. Note that only tickers that have changed will be present in the array.
**Stream Name:** !ticker\_<window-size>@arr
**Window Size:** 1h,4h,1d
**Update Speed:** 1000ms
**Payload:**
```
[ { // Same as <symbol>@ticker_<window_size> payload, // one for each symbol updated within the interval. }]
```
## Individual Symbol Book Ticker Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Pushes any update to the best bid or ask's price or quantity in real-time for a specified symbol. Multiple `<symbol>@bookTicker` streams can be subscribed to over one connection.
**Stream Name:** <symbol>@bookTicker
**Update Speed:** Real-time
**Payload:**
```
{ "u": 400900217, // order book updateId "s": "BNBUSDT", // symbol "b": "25.35190000", // best bid price "B": "31.21000000", // best bid qty "a": "25.36520000", // best ask price "A": "40.66000000" // best ask qty}
```
## Average Price[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
Average price streams push changes in the average price over a fixed time interval.
**Stream Name:** <symbol>@avgPrice
**Update Speed:** 1000ms
**Payload:**
```
{ "e": "avgPrice", // Event type "E": 1693907033000, // Event time "s": "BTCUSDT", // Symbol "i": "5m", // Average price interval "w": "25776.86000000", // Average price "T": 1693907032213 // Last trade time}
```
## Partial Book Depth Streams[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-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:**
```
{ "lastUpdateId": 160, // Last update ID "bids": [ // Bids to be updated [ "0.0024", // Price level to be updated "10" // Quantity ] ], "asks": [ // Asks to be updated [ "0.0026", // Price level to be updated "100" // Quantity ] ]}
```
## Diff. Depth Stream[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
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:**
```
{ "e": "depthUpdate", // Event type "E": 1672515782136, // Event time "s": "BNBBTC", // Symbol "U": 157, // First update ID in event "u": 160, // Final update ID in event "b": [ // Bids to be updated [ "0.0024", // Price level to be updated "10" // Quantity ] ], "a": [ // Asks to be updated [ "0.0026", // Price level to be updated "100" // Quantity ] ]}
```
## How to manage a local order book correctly[](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
1. Open a WebSocket connection to `wss://stream.binance.com:9443/ws/bnbbtc@depth`.
2. Buffer the events received from the stream. Note the `U` of the first event you received.
3. Get a depth snapshot from `https://api.binance.com/api/v3/depth?symbol=BNBBTC&limit=5000`.
4. If the `lastUpdateId` from the snapshot is strictly less than the `U` from step 2, go back to step 3.
5. In the buffered events, discard any event where `u` is <= `lastUpdateId` of the snapshot. The first buffered event should now have `lastUpdateId` within its `[U;u]` range.
6. Set your local order book to the snapshot. Its update ID is `lastUpdateId`.
7. Apply the update procedure below to all buffered events, and then to all subsequent events received.
To apply an event to your local order book, follow this update procedure:
1. Decide whether the update event can be applied:
- If the event last update ID (`u`) is less than the update ID of your local order book, ignore the event.
- If the event first update ID (`U`) is greater than the update ID of your local order book + 1, you have missed some events.
Discard your local order book and restart the process from the beginning.
- Normally, `U` of the next event is equal to `u + 1` of the previous event.
2. For each price level in bids (`b`) and asks (`a`), set the new quantity in the order book:
- If the price level does not exist in the order book, insert it with new quantity.
- If the quantity is zero, remove the price level from the order book.
3. Set the order book update ID to the last update ID (`u`) in the processed event.
> \[!NOTE\] Since depth snapshots retrieved from the API have a limit on the number of price levels (5000 on each side maximum), you won't learn the quantities for the levels outside of the initial snapshot unless they change.
> So be careful when using the information for those levels, since they might not reflect the full view of the order book.
> However, for most use cases, seeing 5000 levels on each side is enough to understand the market and trade effectively.
- [General WSS information](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [WebSocket Limits](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Live Subscribing/Unsubscribing to streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Subscribe to a stream](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Unsubscribe to a stream](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Listing Subscriptions](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Setting Properties](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Retrieving Properties](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Error Messages](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Aggregate Trade Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Trade Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Kline/Candlestick Streams for UTC](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Kline/Candlestick Streams with timezone offset](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Individual Symbol Mini Ticker Stream](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [All Market Mini Tickers Stream](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Individual Symbol Ticker Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Individual Symbol Rolling Window Statistics Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [All Market Rolling Window Statistics Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Individual Symbol Book Ticker Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Average Price](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Partial Book Depth Streams](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [Diff. Depth Stream](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
- [How to manage a local order book correctly](https://developers.binance.com/docs/binance-spot-api-docs/web-socket-streams)
File diff suppressed because it is too large Load Diff
@@ -1,111 +0,0 @@
---
title: "Authentication requests | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests"
fetched_at: "2026-02-26T10:38:12.599Z"
---
**Note:** Only _Ed25519_ keys are supported for this feature.
### Log in with API key (SIGNED)[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests)
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "method": "session.logon", "params": { "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "1cf54395b336b0a9727ef27d5d98987962bc47aca6e13fe978612d0adee066ed", "timestamp": 1649729878532 }}
```
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
**Parameters:**
Name
Type
Mandatory
Description
`apiKey`
STRING
YES
`recvWindow`
DECIMAL
NO
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
`signature`
STRING
YES
`timestamp`
LONG
YES
**Data Source:** Memory
**Response:**
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "status": 200, "result": { "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "authorizedSince": 1649729878532, "connectedSince": 1649729873021, "returnRateLimits": false, "serverTime": 1649729878630, "userDataStream": false // is User Data Stream subscription active? }}
```
### Query session status[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests)
```
{ "id": "b50c16cd-62c9-4e29-89e4-37f10111f5bf", "method": "session.status"}
```
Query the status of the WebSocket connection, inspecting which API key (if any) is used to authorize requests.
**Weight:** 2
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "b50c16cd-62c9-4e29-89e4-37f10111f5bf", "status": 200, "result": { // if the connection is not authenticated, "apiKey" and "authorizedSince" will be shown as null "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "authorizedSince": 1649729878532, "connectedSince": 1649729873021, "returnRateLimits": false, "serverTime": 1649730611671, "userDataStream": true // is User Data Stream subscription active? }}
```
### Log out of the session[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests)
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "method": "session.logout"}
```
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
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "c174a2b1-3f51-4580-b200-8528bd237cb7", "status": 200, "result": { "apiKey": null, "authorizedSince": null, "connectedSince": 1649729873021, "returnRateLimits": false, "serverTime": 1649730611671, "userDataStream": false // is User Data Stream subscription active? }}
```
- [Log in with API key (SIGNED)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests)
- [Query session status](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests)
- [Log out of the session](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests)
@@ -1,37 +0,0 @@
---
title: "Data sources | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/data-sources"
fetched_at: "2026-02-26T10:38:12.732Z"
---
- The API system is asynchronous. Some delay in the response is normal and expected.
- Each method has a data source indicating where the data is coming from, and thus how up-to-date it is.
Data Source
Latency
Description
Matching Engine
lowest
The Matching Engine produces the response directly
Memory
low
Data is fetched from API server's local or external memory cache
Database
moderate
Data is retrieved from the database
- Some methods have more than one data source (e.g., Memory => Database).
This means that the API will look for the latest data in that order: first in the cache, then in the database.
@@ -1,42 +0,0 @@
---
title: "Event format | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/event-format"
fetched_at: "2026-02-26T10:38:12.736Z"
---
[User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream) events for non-SBE sessions are sent as JSON in **text frames**, one event per frame.
Events in [SBE sessions](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) will be sent as **binary frames**.
Please refer to [`userDataStream.subscribe`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests) for details on how to subscribe to User Data Stream in WebSocket API.
Example of an event:
```
{ "subscriptionId": 0, "event": { "e": "outboundAccountPosition", "E": 1728972148778, "u": 1728972148778, "B": [ { "a": "BTC", "f": "11818.00000000", "l": "182.00000000" }, { "a": "USDT", "f": "10580.00000000", "l": "70.00000000" } ] }}
```
Event fields:
Name
Type
Mandatory
Description
`event`
OBJECT
YES
Event payload. See [User Data Streams](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream)
`subscriptionId`
INT
NO
Identifies which subscription the event is coming from. See [User Data Stream subscriptions](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/event-format)
@@ -1,30 +0,0 @@
---
title: "General API Information | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-api-information"
fetched_at: "2026-02-26T10:38:12.847Z"
---
- The base endpoint is: **`wss://ws-api.binance.com:443/ws-api/v3`**.
- If you experience issues with the standard 443 port, alternative port 9443 is also available.
- The base endpoint for [testnet](https://testnet.binance.vision/) is: `wss://ws-api.testnet.binance.vision/ws-api/v3`
- A single connection to the API is only valid for 24 hours; expect to be disconnected after the 24-hour mark.
- We support HMAC, RSA, and Ed25519 keys. For more information, please see [API Key types](https://developers.binance.com/docs/binance-spot-api-docs/faqs/api_key_types).
- Responses are in JSON by default. To receive responses in SBE, refer to the [SBE FAQ](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) page.
- If your request contains a symbol name containing non-ASCII characters, then the response may contain non-ASCII characters encoded in UTF-8.
- Some methods may return asset and/or symbol names containing non-ASCII characters encoded in UTF-8 even if the request did not contain non-ASCII characters.
- The WebSocket server will send a `ping frame` every 20 seconds.
- If the WebSocket server does not receive a `pong frame` back from the connection within a minute the connection will be disconnected.
- When you receive a ping, you must send a pong with a copy of ping's payload as soon as possible.
- Unsolicited `pong frames` are allowed, but will not prevent disconnection. **It is recommended that the payload for these pong frames are empty.**
- Data is returned in **chronological order**, unless noted otherwise.
- Without `startTime` or `endTime`, returns the most recent items up to the limit.
- With `startTime`, returns oldest items from `startTime` up to the limit.
- With `endTime`, returns most recent items up to `endTime` and the limit.
- With both, behaves like `startTime` but does not exceed `endTime`.
- All timestamps in the JSON responses are in **milliseconds in UTC by default**. To receive the information in microseconds, please add the parameter `timeUnit=MICROSECOND` or `timeUnit=microsecond` in the URL.
- Timestamp parameters (e.g. `startTime`, `endTime`, `timestamp`) can be passed in milliseconds or microseconds.
- All field names and values are **case-sensitive**, unless noted otherwise.
- If there are enums or terms you want clarification on, please see [SPOT Glossary](https://developers.binance.com/docs/binance-spot-api-docs/faqs/spot_glossary) for more information.
- APIs have a timeout of 10 seconds when processing a request. If a response from the Matching Engine takes longer than this, the API responds with "Timeout waiting for response from backend server. Send status unknown; execution status unknown." [(-1007 TIMEOUT)](https://developers.binance.com/docs/binance-spot-api-docs/errors)
- This does not always mean that the request failed in the Matching Engine.
- If the status of the request has not appeared in [User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream), please perform an API query for its status.
- **Please avoid SQL keywords in requests** as they may trigger a security block by a WAF (Web Application Firewall) rule. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
@@ -1,131 +0,0 @@
---
title: "General requests | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests"
fetched_at: "2026-02-26T10:38:12.919Z"
---
### Test connectivity[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
```
{ "id": "922bcc6e-9de8-440d-9e84-7c80933a8d0d", "method": "ping"}
```
Test connectivity to the WebSocket API.
**Note:** You can use regular WebSocket ping frames to test connectivity as well, WebSocket API will respond with pong frames as soon as possible. `ping` request along with `time` is a safe way to test request-response handling in your application.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "922bcc6e-9de8-440d-9e84-7c80933a8d0d", "status": 200, "result": {}, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 1 } ]}
```
### Check server time[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
```
{ "id": "187d3cb2-942d-484c-8271-4e2141bbadb1", "method": "time"}
```
Test connectivity to the WebSocket API and get the current server time.
**Weight:** 1
**Parameters:** NONE
**Data Source:** Memory
**Response:**
```
{ "id": "187d3cb2-942d-484c-8271-4e2141bbadb1", "status": 200, "result": { "serverTime": 1656400526260 }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 1 } ]}
```
### Exchange information[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
```
{ "id": "5494febb-d167-46a2-996d-70533eb4d976", "method": "exchangeInfo", "params": { "symbols": ["BNBBTC"] }}
```
Query current exchange trading rules, rate limits, and symbol information.
**Weight:** 20
**Parameters:**
Name
Type
Mandatory
Description
`symbol`
STRING
NO
Describe a single symbol
`symbols`
ARRAY of STRING
Describe multiple symbols
`permissions`
ARRAY of STRING
Filter symbols by permissions
`showPermissionSets`
BOOLEAN
Controls whether the content of the `permissionSets` field is populated or not. Defaults to `true`.
`symbolStatus`
ENUM
Filters for symbols that have this `tradingStatus`.
Valid values: `TRADING`, `HALT`, `BREAK`
Cannot be used in combination with `symbol` or `symbols`
Notes:
- Only one of `symbol`, `symbols`, `permissions` parameters can be specified.
- Without parameters, `exchangeInfo` displays all symbols with `["SPOT, "MARGIN", "LEVERAGED"]` permissions.
- In order to list _all_ active symbols on the exchange, you need to explicitly request all permissions.
- `permissions` accepts either a list of permissions, or a single permission name. E.g. `"SPOT"`.
- [Available Permissions](https://developers.binance.com/docs/binance-spot-api-docs/enums)
**Examples of Symbol Permissions Interpretation from the Response:**
- `[["A","B"]]` means you may place an order if your account has either permission "A" **or** permission "B".
- `[["A"],["B"]]` means you can place an order if your account has permission "A" **and** permission "B".
- `[["A"],["B","C"]]` means you can place an order if your account has permission "A" **and** permission "B" or permission "C". (Inclusive or is applied here, not exclusive or, so your account may have both permission "B" and permission "C".)
**Data Source:** Memory
**Response:**
```
{ "id": "5494febb-d167-46a2-996d-70533eb4d976", "status": 200, "result": { "timezone": "UTC", "serverTime": 1655969291181, // Global rate limits. See "Rate limits" section. "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", // Rate limit type: REQUEST_WEIGHT, ORDERS, CONNECTIONS "interval": "MINUTE", // Rate limit interval: SECOND, MINUTE, DAY "intervalNum": 1, // Rate limit interval multiplier (i.e., "1 minute") "limit": 6000 // Rate limit per interval }, { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000 }, { "rateLimitType": "CONNECTIONS", "interval": "MINUTE", "intervalNum": 5, "limit": 300 } ], // Exchange filters are explained on the "Filters" page: // https://github.com/binance/binance-spot-api-docs/blob/master/filters.md // All exchange filters are optional. "exchangeFilters": [], "symbols": [ { "symbol": "BNBBTC", "status": "TRADING", "baseAsset": "BNB", "baseAssetPrecision": 8, "quoteAsset": "BTC", "quotePrecision": 8, "quoteAssetPrecision": 8, "baseCommissionPrecision": 8, "quoteCommissionPrecision": 8, "orderTypes": [ "LIMIT", "LIMIT_MAKER", "MARKET", "STOP_LOSS_LIMIT", "TAKE_PROFIT_LIMIT" ], "icebergAllowed": true, "ocoAllowed": true, "otoAllowed": true, "opoAllowed": true, "quoteOrderQtyMarketAllowed": true, "allowTrailingStop": true, "cancelReplaceAllowed": true, "amendAllowed": false, "pegInstructionsAllowed": true, "isSpotTradingAllowed": true, "isMarginTradingAllowed": true, // Symbol filters are explained on the "Filters" page: // https://github.com/binance/binance-spot-api-docs/blob/master/filters.md // All symbol filters are optional. "filters": [ { "filterType": "PRICE_FILTER", "minPrice": "0.00000100", "maxPrice": "100000.00000000", "tickSize": "0.00000100" }, { "filterType": "LOT_SIZE", "minQty": "0.00100000", "maxQty": "100000.00000000", "stepSize": "0.00100000" } ], "permissions": [], "permissionSets": [["SPOT", "MARGIN", "TRD_GRP_004"]], "defaultSelfTradePreventionMode": "NONE", "allowedSelfTradePreventionModes": ["NONE"] } ], // Optional field. Present only when SOR is available. // https://github.com/binance/binance-spot-api-docs/blob/master/faqs/sor_faq.md "sors": [ { "baseAsset": "BTC", "symbols": ["BTCUSDT", "BTCUSDC"] } ] }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 20 } ]}
```
- [Test connectivity](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
- [Check server time](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
- [Exchange information](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/general-requests)
File diff suppressed because it is too large Load Diff
@@ -1,178 +0,0 @@
---
title: "Rate limits | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits"
fetched_at: "2026-02-26T10:38:13.003Z"
---
### Connection limits[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
There is a limit of **300 connections per attempt every 5 minutes**.
The connection is per **IP address**.
### General information on rate limits[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
- Current API rate limits can be queried using the [`exchangeInfo`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits) request.
- There are multiple rate limit types across multiple intervals.
- Responses can indicate current rate limit status in the optional `rateLimits` field.
- Requests fail with status `429` when unfilled order count or request rate limits are violated.
#### How to interpret rate limits[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
A response with rate limit status may look like this:
```
{ "id": "7069b743-f477-4ae3-81db-db9b8df085d2", "status": 200, "result": { "serverTime": 1656400526260 }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 70 } ]}
```
The `rateLimits` array describes all currently active rate limits affected by the request.
Name
Type
Mandatory
Description
`rateLimitType`
ENUM
YES
Rate limit type: `REQUEST_WEIGHT`, `ORDERS`
`interval`
ENUM
YES
Rate limit interval: `SECOND`, `MINUTE`, `HOUR`, `DAY`
`intervalNum`
INT
YES
Rate limit interval multiplier
`limit`
INT
YES
Request limit per interval
`count`
INT
YES
Current usage per interval
Rate limits are accounted by intervals.
For example, a `1 MINUTE` interval starts every minute. Request submitted at 00:01:23.456 counts towards the 00:01:00 minute's limit. Once the 00:02:00 minute starts, the count will reset to zero again.
Other intervals behave in a similar manner. For example, `1 DAY` rate limit resets at 00:00 UTC every day, and `10 SECOND` interval resets at 00, 10, 20... seconds of each minute.
APIs have multiple rate-limiting intervals. If you exhaust a shorter interval but the longer interval still allows requests, you will have to wait for the shorter interval to expire and reset. If you exhaust a longer interval, you will have to wait for that interval to reset, even if shorter rate limit count is zero.
#### How to show/hide rate limit information[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
`rateLimits` field is included with every response by default.
However, rate limit information can be quite bulky. If you are not interested in detailed rate limit status of every request, the `rateLimits` field can be omitted from responses to reduce their size.
- Optional `returnRateLimits` boolean parameter in request.
Use `returnRateLimits` parameter to control whether to include `rateLimits` fields in response to individual requests.
Default request and response:
```
{ "id": 1, "method": "time" }
```
```
{ "id": 1, "status": 200, "result": { "serverTime": 1656400526260 }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 70 } ]}
```
Request and response without rate limit status:
```
{ "id": 2, "method": "time", "params": { "returnRateLimits": false } }
```
```
{ "id": 2, "status": 200, "result": { "serverTime": 1656400527891 } }
```
- Optional `returnRateLimits` boolean parameter in connection URL.
If you wish to omit `rateLimits` from all responses by default, use `returnRateLimits` parameter in the query string instead:
```
wss://ws-api.binance.com:443/ws-api/v3?returnRateLimits=false
```
This will make all requests made through this connection behave as if you have passed `"returnRateLimits": false`.
If you _want_ to see rate limits for a particular request, you need to explicitly pass the `"returnRateLimits": true` parameter.
**Note:** Your requests are still rate limited if you hide the `rateLimits` field in responses.
### IP limits[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
- Every request has a certain **weight**, added to your limit as you perform requests.
- The heavier the request (e.g. querying data from multiple symbols), the more weight the request will cost.
- Connecting to WebSocket API costs 2 weight.
- Current weight usage is indicated by the `REQUEST_WEIGHT` rate limit type.
- Use the [`exchangeInfo`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits) request to keep track of the current weight limits.
- Weight is accumulated **per IP address** and is shared by all connections from that address.
- If you go over the weight limit, requests fail with status `429`.
- This status code indicates you should back off and stop spamming the API.
- Rate-limited responses include a `retryAfter` field, indicating when you can retry the request.
- **Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban and you will be disconnected.**
- Requests from a banned IP address fail with status `418`.
- `retryAfter` field indicates the timestamp when the ban will be lifted.
- IP bans are tracked and **scale in duration** for repeat offenders, **from 2 minutes to 3 days**.
Successful response indicating that in 1 minute you have used 70 weight out of your 6000 limit:
```
{ "id": "7069b743-f477-4ae3-81db-db9b8df085d2", "status": 200, "result": [], "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 70 } ]}
```
Failed response indicating that you are banned and the ban will last until epoch `1659146400000`:
```
{ "id": "fc93a61a-a192-4cf4-bb2a-a8f0f0c51e06", "status": 418, "error": { "code": -1003, "msg": "Way too much request weight used; IP banned until 1659146400000. Please use WebSocket Streams for live updates to avoid bans.", "data": { "serverTime": 1659142907531, "retryAfter": 1659146400000 } }, "rateLimits": [ { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 2411 } ]}
```
### Unfilled Order Count[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
- Successfully placed orders update the `ORDERS` rate limit type.
- Rejected or unsuccessful orders might or might not update the `ORDERS` rate limit type.
- **Please note that if your orders are consistently filled by trades, you can continuously place orders on the API**. For more information, please see [Spot Unfilled Order Count Rules](https://developers.binance.com/docs/binance-spot-api-docs/faqs/order_count_decrement).
- Use the [`account.rateLimits.orders`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/account-requests) request to keep track of how many orders you have placed within this interval.
- If you exceed this, requests fail with status `429`.
- This status code indicates you should back off and stop spamming the API.
- Responses that have a status `429` include a `retryAfter` field, indicating when you can retry the request.
- This is maintained **per account** and is shared by all API keys of the account.
Successful response indicating that you have placed 12 orders in 10 seconds, and 4043 orders in the past 24 hours:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "status": 200, "result": { "symbol": "BTCUSDT", "orderId": 12510053279, "orderListId": -1, "clientOrderId": "a097fe6304b20a7e4fc436", "transactTime": 1655716096505, "price": "0.10000000", "origQty": "10.00000000", "executedQty": "0.00000000", "origQuoteOrderQty": "0.000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1655716096505, "selfTradePreventionMode": "NONE" }, "rateLimits": [ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 12 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 4043 }, { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 321 } ]}
```
- [Connection limits](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
- [General information on rate limits](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
- [IP limits](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
- [Unfilled Order Count](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/rate-limits)
@@ -1,54 +0,0 @@
---
title: "Request format | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-format"
fetched_at: "2026-02-26T10:38:13.107Z"
---
Requests must be sent as JSON in **text frames**, one request per frame.
Example of request:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "BUY", "type": "LIMIT", "price": "0.1", "quantity": "10", "timeInForce": "GTC", "timestamp": 1655716096498, "apiKey": "T59MTDLWlpRW16JVeZ2Nju5A5C98WkMm8CSzWC4oqynUlTm1zXOxyauT8LmwXEv9", "signature": "5942ad337e6779f2f4c62cd1c26dba71c91514400a24990a3e7f5edec9323f90" }}
```
Request fields:
Name
Type
Mandatory
Description
`id`
INT / STRING / `null`
YES
Arbitrary ID used to match responses to requests
`method`
STRING
YES
Request method name
`params`
OBJECT
NO
Request parameters. May be omitted if there are no parameters
- Request `id` is truly arbitrary. You can use UUIDs, sequential IDs, current timestamp, etc. The server does not interpret `id` in any way, simply echoing it back in the response.
You can freely reuse IDs within a session. However, be careful to not send more than one request at a time with the same ID, since otherwise it might be impossible to tell the responses apart.
- Request method names may be prefixed with explicit version: e.g., `"v3/order.place"`.
- The order of `params` is not significant.
@@ -1,589 +0,0 @@
---
title: "Request security | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security"
fetched_at: "2026-02-26T10:38:13.191Z"
---
- Each method has a security type indicating required API key permissions, shown next to the method name (e.g., [Place new order (TRADE)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)).
- If unspecified, the security type is `NONE`.
- Except for `NONE`, all methods with a security type are considered `SIGNED` requests (i.e. including a `signature`), except for [listenKey management](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security).
- Secure methods require a valid API key to be specified and authenticated.
- API keys can be created on the [API Management](https://www.binance.com/en/support/faq/360002502072) page of your Binance account.
- **Both API key and secret key are sensitive.** Never share them with anyone. If you notice unusual activity in your account, immediately revoke all the keys and contact Binance support.
- API keys can be configured to allow access only to certain types of secure methods.
- For example, you can have an API key with `TRADE` permission for trading, while using a separate API key with `USER_DATA` permission to monitor your order status.
- By default, an API key cannot `TRADE`. You need to enable trading in API Management first.
Security type
Description
`NONE`
Public market data
`TRADE`
Trading on the exchange, placing and canceling orders
`USER_DATA`
Private account information, such as order status and your trading history
`USER_STREAM`
Managing User Data Stream subscriptions
### SIGNED request security[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- `SIGNED` requests require an additional parameter: `signature`, authorizing the request.
#### Signature Case Sensitivity[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- **HMAC:** Signatures generated using HMAC are **not case-sensitive**. This means the signature string can be verified regardless of letter casing.
- **RSA:** Signatures generated using RSA are **case-sensitive**.
- **Ed25519:** Signatures generated using ED25519 are also **case-sensitive**
Please consult [SIGNED request example (HMAC)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security), [SIGNED request example (RSA)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security), and [SIGNED request example (Ed25519)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security) on how to compute signature, depending on which API key type you are using.
### Timing security[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- `SIGNED` requests also require a `timestamp` parameter which should be the current timestamp either in milliseconds or microseconds. (See [General API Information](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security))
- An additional optional parameter, `recvWindow`, specifies for how long the request stays valid and may only be specified in milliseconds.
- `recvWindow` supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
- If `recvWindow` is not sent, **it defaults to 5000 milliseconds**.
- Maximum `recvWindow` is 60000 milliseconds.
- Request processing logic is as follows:
```
serverTime = getCurrentTime()if (timestamp < (serverTime + 1 second) && (serverTime - timestamp) <= recvWindow) { // begin processing request serverTime = getCurrentTime() if (serverTime - timestamp) <= recvWindow { // forward request to Matching Engine } else { // reject request } // finish processing 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!**
### SIGNED request example (HMAC)[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
Here is a step-by-step guide on how to sign requests using an HMAC secret key.
Example API key and secret key:
Key
Value
`apiKey`
`vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A`
`secretKey`
`NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j`
**WARNING: DO NOT SHARE YOUR API KEY AND SECRET KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "------ FILL ME ------" }}
```
Example of a request with a symbol name containing non-ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "------ FILL ME ------" }}
```
As you can see, the `signature` parameter is currently missing.
**Step 1: Construct the signature payload**
Take all request `params` except `signature` and **sort them in alphabetical order by parameter name**:
For the first set of example parameters (ASCII only):
Parameter
Value
`apiKey`
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
`price`
52000.00
`quantity`
0.01000000
`recvWindow`
100
`side`
SELL
`symbol`
BTCUSDT
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
For the second set of example parameters (some non-ASCII characters):
Parameter
Value
`apiKey`
vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A
`price`
0.10000000
`quantity`
1.00000000
`recvWindow`
5000
`side`
BUY
`symbol`
123456
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
Format parameters as `parameter=value` pairs separated by `&`. Values need to be encoded in UTF-8.
For the first set of example parameters (ASCII only), the signature payload should look like this:
```
apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
```
apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
**Step 2: Compute the signature**
1. Use the `secretKey` of your API key as the signing key for the HMAC-SHA-256 algorithm.
2. Sign the UTF-8 bytes of the signature payload constructed in Step 1.
3. Encode the HMAC-SHA-256 output as a hex string.
Note that `apiKey`, `secretKey`, and the payload are **case-sensitive**, while the resulting signature value is case-insensitive.
You can cross-check your signature algorithm implementation with OpenSSL:
For the first set of example parameters (ASCII only):
```
$ echo -n 'apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -hex -sha256 -hmac 'NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j'aa1b5712c094bc4e57c05a1a5c1fd8d88dcd628338ea863fec7b88e59fe2db24
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n 'apiKey=vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -hex -sha256 -hmac 'NhqPtmdSJYdKjVHjA7PZj4Mge3R5YNiP1e3UZjInClVN65XAbvqqM6A7H5fATj0j'b33892ae8e687c939f4468c6268ddd4c40ac1af18ad19a064864c47bae0752cd
```
**Step 3: Add `signature` to request `params`**
Complete the request by adding the `signature` parameter with the signature string.
For the first set of example parameters (ASCII only):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "aa1b5712c094bc4e57c05a1a5c1fd8d88dcd628338ea863fec7b88e59fe2db24" }}
```
For the second set of example parameters (some non-ASCII characters):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "1.00000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "vmPUZE6mv9SD5VNHk4HlWFsOr6aKE2zvsw0MuIgwCIPy6utIco14y7Ju91duEh8A", "signature": "b33892ae8e687c939f4468c6268ddd4c40ac1af18ad19a064864c47bae0752cd" }}
```
### SIGNED request example (RSA)[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
Here is a step-by-step guide on how to sign requests using an RSA private key.
Key
Value
`apiKey`
`CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ`
These examples assume the private key is stored in the file `test-rsa-prv.pem`.
**WARNING: DO NOT SHARE YOUR API KEY AND PRIVATE KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "------ FILL ME ------" }}
```
Example of a request with a symbol name containing non-ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "------ FILL ME ------" }}
```
**Step 1: Construct the signature payload**
Take all request `params` except `signature` and **sort them in alphabetical order by parameter name**:
For the first set of example parameters (ASCII only):
Parameter
Value
`apiKey`
CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ
`price`
52000.00
`quantity`
0.01000000
`recvWindow`
100
`side`
SELL
`symbol`
BTCUSDT
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
For the second set of example parameters (some non-ASCII characters):
Parameter
Value
`apiKey`
CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ
`price`
0.10000000
`quantity`
1.00000000
`recvWindow`
5000
`side`
BUY
`symbol`
123456
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
Format parameters as `parameter=value` pairs separated by `&`. Values need to be encoded in UTF-8.
For the first set of example parameters (ASCII only), the signature payload should look like this:
```
apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
```
apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
**Step 2: Compute the signature**
1. Sign the UTF-8 bytes of the signature payload constructed in Step 1 using the RSASSA-PKCS1-v1\_5 algorithm with SHA-256 hash function.
2. Encode the output in base64.
Note that `apiKey`, the payload, and the resulting `signature` are **case-sensitive**.
You can cross-check your signature algorithm implementation with OpenSSL:
For the first set of example parameters (ASCII only):
```
$ echo -n 'apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -sha256 -sign test-rsa-prv.pem \ | openssl enc -base64 -AOJJaf8C/3VGrU4ATTR4GiUDqL2FboSE1Qw7UnnoYNfXTXHubIl1iaePGuGyfct4NPu5oVEZCH4Q6ZStfB1w4ssgu0uiB/Bg+fBrRFfVgVaLKBdYHMvT+ljUJzqVaeoThG9oXlduiw8PbS9U8DYAbDvWN3jqZLo4Z2YJbyovyDAvDTr/oC0+vssLqP7NmlNb3fF3Bj7StmOwJvQJTbRAtzxK5PP7OQe+0mbW+D7RqVkUiSswR8qJFWTeSe4nXXNIdZdueYhF/Xf25L+KitJS5IHdIHcKfEw3MQzHFb2ZsGWkjDQwxkwr7Noi0Zaa+gFtxCuatGFm9dFIyx217pmSHtA==
```
For the second set of example parameters (some non-ASCII characters):
```
$ echo -n 'apiKey=CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT' \ | openssl dgst -sha256 -sign test-rsa-prv.pem \ | openssl enc -base64 -AF3o/79Ttvl2cVYGPfBOF3oEOcm5QcYmTYWpdVIrKve5u+8paMNDAdUE+teqMxFM9HcquetGcfuFpLYtsQames5bDx/tskGM76TWW8HaM+6tuSYBSFLrKqChfA9hQGLYGjAiflf1YBnDhY+7vNbJFusUborNOloOj+ufzP5q42PvI3H0uNy3W5V3pyfXpDGCBtfCYYr9NAqA4d+AQfyllL/zkO9h9JSdozN49t0/hWGoD2dWgSO0Je6MytKEvD4DQXGeqNlBTB6tUXcWnRW+FcaKZ4KYqnxCtb1u8rFXUYgFykr2CbcJLSmw6ydEJ3EZ/NaZopRr+cU0W2m0HZ3qucw==
```
**Step 3: Add `signature` to request `params`**
Complete the request by adding the `signature` parameter with the signature string.
For the first set of example parameters (ASCII only):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "newOrderRespType": "ACK", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "OJJaf8C/3VGrU4ATTR4GiUDqL2FboSE1Qw7UnnoYNfXTXHubIl1iaePGuGyfct4NPu5oVEZCH4Q6ZStfB1w4ssgu0uiB/Bg+fBrRFfVgVaLKBdYHMvT+ljUJzqVaeoThG9oXlduiw8PbS9U8DYAbDvWN3jqZLo4Z2YJbyovyDAvDTr/oC0+vssLqP7NmlNb3fF3Bj7StmOwJvQJTbRAtzxK5PP7OQe+0mbW+D7RqVkUiSswR8qJFWTeSe4nXXNIdZdueYhF/Xf25L+KitJS5IHdIHcKfEw3MQzHFb2ZsGWkjDQwxkwr7Noi0Zaa+gFtxCuatGFm9dFIyx217pmSHtA==" }}
```
For the second set of example parameters (some non-ASCII characters):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "1.00000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ", "signature": "F3o/79Ttvl2cVYGPfBOF3oEOcm5QcYmTYWpdVIrKve5u+8paMNDAdUE+teqMxFM9HcquetGcfuFpLYtsQames5bDx/tskGM76TWW8HaM+6tuSYBSFLrKqChfA9hQGLYGjAiflf1YBnDhY+7vNbJFusUborNOloOj+ufzP5q42PvI3H0uNy3W5V3pyfXpDGCBtfCYYr9NAqA4d+AQfyllL/zkO9h9JSdozN49t0/hWGoD2dWgSO0Je6MytKEvD4DQXGeqNlBTB6tUXcWnRW+FcaKZ4KYqnxCtb1u8rFXUYgFykr2CbcJLSmw6ydEJ3EZ/NaZopRr+cU0W2m0HZ3qucw==" }}
```
### SIGNED Request Example (Ed25519)[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
**Note: It is highly recommended to use Ed25519 API keys as they will provide the best performance and security out of all supported key types.**
Here is a step-by-step guide on how to sign requests using an Ed25519 private key.
Key
Value
`apiKey`
`4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO`
These examples assume the private key is stored in the file `test-ed25519-prv.pem`.
**WARNING: DO NOT SHARE YOUR API KEY AND PRIVATE KEY WITH ANYONE.**
The example keys are provided here only for illustrative purposes.
Example of request with a symbol name comprised entirely of ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "------ FILL ME ------" }}
```
Example of a request with a symbol name containing non-ASCII characters:
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "BUY", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "------ FILL ME ------" }}
```
**Step 1: Construct the signature payload**
Take all request `params` except `signature` and **sort them in alphabetical order by parameter name**:
For the first set of example parameters (ASCII only):
Parameter
Value
`apiKey`
4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO
`price`
52000.00
`quantity`
0.01000000
`recvWindow`
100
`side`
SELL
`symbol`
BTCUSDT
`timeInForce`
GTC
`timestamp`
1645423376532
`type`
LIMIT
For the second set of example parameters (some non-ASCII characters):
Parameter
Value
`apiKey`
4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO
`price`
0.20000000
`quantity`
1.00000000
`recvWindow`
5000
`side`
SELL
`symbol`
123456
`timeInForce`
GTC
`timestamp`
1668481559918
`type`
LIMIT
Format parameters as `parameter=value` pairs separated by `&`. Values need to be encoded in UTF-8.
For the first set of example parameters (ASCII only), the signature payload should look like this:
```
apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
```
apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT
```
**Step 2: Compute the signature**
1. Sign the UTF-8 bytes of your signature payload constructed in Step 1 using the Ed25519 private key.
2. Encode the output in base64.
Note that `apiKey`, the payload, and the resulting `signature` are **case-sensitive**.
You can cross-check your signature algorithm implementation with OpenSSL:
For the first set of example parameters (ASCII only):
```
echo -n "apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=52000.00&quantity=0.01000000&recvWindow=100&side=SELL&symbol=BTCUSDT&timeInForce=GTC&timestamp=1645423376532&type=LIMIT" \ | openssl dgst -sign ./test-ed25519-prv.pem \ | openssl enc -base64 -AEocljwPl29jDxWYaaRaOo4pJ9wEblFbklJvPugNscLLuKd5vHM2grWjn1z+rY0aJ7r/44enxHL6mOAJuJ1kqCg==
```
For the second set of example parameters (some non-ASCII characters):
```
echo -n "apiKey=4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO&price=0.10000000&quantity=1.00000000&recvWindow=5000&side=BUY&symbol=123456&timeInForce=GTC&timestamp=1645423376532&type=LIMIT" \ | openssl dgst -sign ./test-ed25519-prv.pem \ | openssl enc -base64 -AdtNHJeyKry+cNjiGv+sv5kynO9S40tf8k7D5CfAEQAp0s2scunZj+ovJdz2OgW8XhkB9G3/HmASkA9uY9eyFCA==
```
**Step 3: Add the signature to request `params`**
For the first set of example parameters (ASCII only):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "BTCUSDT", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "0.01000000", "price": "52000.00", "newOrderRespType": "ACK", "recvWindow": 100, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "EocljwPl29jDxWYaaRaOo4pJ9wEblFbklJvPugNscLLuKd5vHM2grWjn1z+rY0aJ7r/44enxHL6mOAJuJ1kqCg==" }}
```
For the second set of example parameters (some non-ASCII characters):
```
{ "id": "4885f793-e5ad-4c3b-8f6c-55d891472b71", "method": "order.place", "params": { "symbol": "123456", "side": "SELL", "type": "LIMIT", "timeInForce": "GTC", "quantity": "1.00000000", "price": "0.10000000", "recvWindow": 5000, "timestamp": 1645423376532, "apiKey": "4yNzx3yWC5bS6YTwEkSRaC0nRmSQIIStAUOh1b6kqaBrTLIhjCpI5lJH8q8R8WNO", "signature": "dtNHJeyKry+cNjiGv+sv5kynO9S40tf8k7D5CfAEQAp0s2scunZj+ovJdz2OgW8XhkB9G3/HmASkA9uY9eyFCA==" }}
```
Here is a sample Python script performing all the steps above:
```
#!/usr/bin/env python3import base64import timeimport jsonfrom cryptography.hazmat.primitives.serialization import load_pem_private_keyfrom websocket import create_connection# Set up authenticationAPI_KEY='put your own API Key here'PRIVATE_KEY_PATH='test-prv-key.pem'# Load the private key.# In this example the key is expected to be stored without encryption,# but we recommend using a strong password for improved security.with open(PRIVATE_KEY_PATH, 'rb') as f: private_key = load_pem_private_key(data=f.read(), password=None)# Set up the request parametersparams = { 'apiKey': API_KEY, 'symbol': '123456', 'side': 'SELL', 'type': 'LIMIT', 'timeInForce': 'GTC', 'quantity': '1.0000000', 'price': '0.10000000', 'recvWindow': 5000}# Timestamp the requesttimestamp = int(time.time() * 1000) # UNIX timestamp in millisecondsparams['timestamp'] = timestamp# Sort parameters alphabetically by nameparams = dict(sorted(params.items()))# Compute the signature payloadpayload = '&'.join([f"{k}={v}" for k,v in params.items()]) # no percent encoding here!# Sign the requestsignature = base64.b64encode(private_key.sign(payload.encode('UTF-8')))params['signature'] = signature.decode('ASCII')# Send the requestrequest = { 'id': 'my_new_order', 'method': 'order.place', 'params': params}ws = create_connection("wss://ws-api.binance.com:443/ws-api/v3")ws.send(json.dumps(request))result = ws.recv()ws.close()print(result)
```
- [SIGNED request security](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- [Timing security](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- [SIGNED request example (HMAC)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- [SIGNED request example (RSA)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
- [SIGNED Request Example (Ed25519)](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/request-security)
@@ -1,86 +0,0 @@
---
title: "Response format | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/response-format"
fetched_at: "2026-02-26T10:38:13.259Z"
---
Responses are returned as JSON in **text frames**, one response per frame.
Example of successful response:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "status": 200, "result": { "symbol": "BTCUSDT", "orderId": 12510053279, "orderListId": -1, "clientOrderId": "a097fe6304b20a7e4fc436", "transactTime": 1655716096505, "price": "0.10000000", "origQty": "10.00000000", "executedQty": "0.00000000", "origQuoteOrderQty": "0.000000", "cummulativeQuoteQty": "0.00000000", "status": "NEW", "timeInForce": "GTC", "type": "LIMIT", "side": "BUY", "workingTime": 1655716096505, "selfTradePreventionMode": "NONE" }, "rateLimits": [ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 12 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 4043 }, { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 321 } ]}
```
Example of failed response:
```
{ "id": "e2a85d9f-07a5-4f94-8d5f-789dc3deb097", "status": 400, "error": { "code": -2010, "msg": "Account has insufficient balance for requested action." }, "rateLimits": [ { "rateLimitType": "ORDERS", "interval": "SECOND", "intervalNum": 10, "limit": 50, "count": 13 }, { "rateLimitType": "ORDERS", "interval": "DAY", "intervalNum": 1, "limit": 160000, "count": 4044 }, { "rateLimitType": "REQUEST_WEIGHT", "interval": "MINUTE", "intervalNum": 1, "limit": 6000, "count": 322 } ]}
```
Response fields:
Name
Type
Mandatory
Description
`id`
INT / STRING / `null`
YES
Same as in the original request
`status`
INT
YES
Response status. See [Status codes](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/response-format)
`result`
OBJECT / ARRAY
YES
Response content. Present if request succeeded
`error`
OBJECT
Error description. Present if request failed
`rateLimits`
ARRAY
NO
Rate limiting status. See [Rate limits](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/response-format)
### Status codes[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/response-format)
Status codes in the `status` field are the same as in HTTP.
Here are some common status codes that you might encounter:
- `200` indicates a successful response.
- `4XX` status codes indicate invalid requests; the issue is on your side.
- `400` your request failed, see `error` for the reason.
- `403` you have been blocked by the Web Application Firewall. This can indicate a rate limit violation or a security block. See [https://www.binance.com/en/support/faq/detail/360004492232](https://www.binance.com/en/support/faq/detail/360004492232) for more details.
- `409` your request partially failed but also partially succeeded, see `error` for details.
- `418` you have been auto-banned for repeated violation of rate limits.
- `429` you have exceeded API request rate limit, please slow down.
- `5XX` status codes indicate internal errors; the issue is on Binance's side.
- **Important:** If a response contains 5xx status code, it **does not** necessarily mean that your request has failed. Execution status is _unknown_ and the request might have actually succeeded. Please use query methods to confirm the status. You might also want to establish a new WebSocket connection for that.
See [Error codes for Binance](https://developers.binance.com/docs/binance-spot-api-docs/errors) for a list of error codes and messages.
- [Status codes](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/response-format)
@@ -1,37 +0,0 @@
---
title: "Session Authentication | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication"
fetched_at: "2026-02-26T10:38:13.356Z"
---
**Note:** Only _Ed25519_ keys are supported for this feature.
If you do not want to specify `apiKey` and `signature` in each individual request, you can authenticate your API key for the active WebSocket session.
Once authenticated, you no longer have to specify `apiKey` and `signature` for those requests that need them. Requests will be performed on behalf of the account owning the authenticated API key.
**Note:** You still have to specify the `timestamp` parameter for `SIGNED` requests.
### Authenticate after connection[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication)
You can authenticate an already established connection using session authentication requests:
- [`session.logon`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication) authenticate, or change the API key associated with the connection
- [`session.status`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication) check connection status and the current API key
- [`session.logout`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication) forget the API key associated with the connection
**Regarding API key revocation:**
If during an active session the API key becomes invalid for _any reason_ (e.g. IP address is not whitelisted, API key was deleted, API key doesn't have correct permissions, etc), after the next request the session will be revoked with the following error message:
```
{ "id": null, "status": 401, "error": { "code": -2015, "msg": "Invalid API-key, IP, or permissions for action." }}
```
### Authorize _ad hoc_ requests[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication)
Only one API key can be authenticated with the WebSocket connection. The authenticated API key is used by default for requests that require an `apiKey` parameter. However, you can always specify the `apiKey` and `signature` explicitly for individual requests, overriding the authenticated API key and using a different one to authorize a specific request.
For example, you might want to authenticate your `USER_DATA` key to be used by default, but specify the `TRADE` key with an explicit signature when placing orders.
- [Authenticate after connection](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication)
- [Authorize _ad hoc_ requests](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/session-authentication)
File diff suppressed because it is too large Load Diff
@@ -1,164 +0,0 @@
---
title: "User Data Stream requests | Binance Open Platform"
source: "https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests"
fetched_at: "2026-02-26T10:38:13.543Z"
---
### User Data Stream subscription[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests)
**General information:**
- [User Data Stream](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream) subscriptions allow you to receive all the events related to a given account on a WebSocket connection.
- There are 2 ways to start a subscription:
- If you have an authenticated session, then you can subscribe to events for that authenticated account using [`userDataStream.subscribe`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests).
- In any session, authenticated or not, you can subscribe to events for one or more accounts for which you can provide an API Key signature, using [`userDataStream.subscribe.signature`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests).
- You can have only one active subscription for a given account on a given connection.
- Subscriptions are identified by a `subscriptionId` which is returned when starting the subscription. That `subscriptionId` allows you to map the events you receive to a given subscription.
- All active subscriptions for a session can be found using [`session.subscriptions`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests).
- Limits
- A single session supports **up to 1,000 active subscriptions** simultaneously.
- Attempting to start a new subscription beyond this limit will result in an error.
- If your accounts are very active, we suggest not opening too many subscriptions at once, in order to not overload your connection.
- A single session can handle a maximum of **65,535 total subscriptions** over its lifetime.
- If this limit is reached, you will receive an error and must re-establish a new connection to be able to start new subscriptions.
- To verify the status of User Data Stream subscriptions, check the `userDataStream` field in [`session.status`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests):
- `null` - User Data Stream subscriptions are **not available** on this WebSocket API.
- `true` - There is at **least one subscription active** in this session.
- `false` - There are **no active subscriptions** in this session.
#### Subscribe to User Data Stream (USER\_STREAM)[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests)
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "method": "userDataStream.subscribe"}
```
Subscribe to the User Data Stream in the current WebSocket connection.
**Notes:**
- This method requires an authenticated WebSocket connection using Ed25519 keys. Please refer to [`session.logon`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests).
- To check the subscription status, use [`session.status`](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/authentication-requests), see the `userDataStream` flag indicating you have have an active subscription.
- User Data Stream events are available in both JSON and [SBE](https://developers.binance.com/docs/binance-spot-api-docs/faqs/sbe_faq) sessions.
- Please refer to [User Data Streams](https://developers.binance.com/docs/binance-spot-api-docs/user-data-stream) for the event format details.
- For SBE, only SBE schema 2:1 or later is supported.
**Weight**: 2
**Parameters**: NONE
**Response**:
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "status": 200, "result": { "subscriptionId": 0 }}
```
#### Unsubscribe from User Data Stream[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests)
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "method": "userDataStream.unsubscribe"}
```
Stop listening to the User Data Stream in the current WebSocket connection.
Note that `session.logout` will only close the subscription created with `userDataStream.subscribe` but not subscriptions opened with `userDataStream.subscribe.signature`.
**Weight**: 2
**Parameters**:
Name
Type
Mandatory
Description
`subscriptionId`
INT
No
When called with no parameter, this will close all subscriptions.
When called with the `subscriptionId` parameter, this will attempt to close the subscription with that subscription id, if it exists.
**Response**:
```
{ "id": "d3df8a21-98ea-4fe0-8f4e-0fcea5d418b7", "status": 200, "result": {}}
```
#### Listing all subscriptions[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests)
```
{ "id": "d3df5a22-88ea-4fe0-9f4e-0fcea5d418b7", "method": "session.subscriptions", "params": {}}
```
**Note:**
- Users are expected to track on their side which subscription corresponds to which account.
**Weight**: 2
**Data Source**: Memory
**Response**:
```
{ "id": "d3df5a22-88ea-4fe0-9f4e-0fcea5d418b7", "status": 200, "result": [ { "subscriptionId": 0 }, { "subscriptionId": 1 } ]}
```
#### Subscribe to User Data Stream through signature subscription (USER\_STREAM)[](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests)
```
{ "id": "d3df8a22-98ea-4fe0-9f4e-0fcea5d418b7", "method": "userDataStream.subscribe.signature", "params": { "apiKey": "mjcKCrJzTU6TChLsnPmgnQJJMR616J4yWvdZWDUeXkk6vL6dLyS7rcVOQlADlVjA", "timestamp": 1747385641636, "signature": "yN1vWpXb+qoZ3/dGiFs9vmpNdV7e3FxkA+BstzbezDKwObcijvk/CVkWxIwMCtCJbP270R0OempYwEpS6rDZCQ==" }}
```
**Weight:** 2
**Parameters**:
Name
Type
Mandatory
Description
`apiKey`
STRING
Yes
`timestamp`
LONG
Yes
`signature`
STRING
Yes
`recvWindow`
DECIMAL
No
The value cannot be greater than `60000`.
Supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.
**Data Source:** Memory
**Response:**
```
{ "id": "d3df8a22-98ea-4fe0-9f4e-0fcea5d418b7", "status": 200, "result": { "subscriptionId": 0 }}
```
- [User Data Stream subscription](https://developers.binance.com/docs/binance-spot-api-docs/websocket-api/user-data-stream-requests)
@@ -1,10 +0,0 @@
---
title: "Introduction | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/Introduction"
fetched_at: "2026-01-27T05:28:00.328Z"
---
!function(){function t(t){document.documentElement.setAttribute("data-theme",t)}var e=function(){try{return new URLSearchParams(window.location.search).get("docusaurus-theme")}catch(t){}}()||function(){try{return window.localStorage.getItem("theme")}catch(t){}}();t(null!==e?e:"light")}(),function(){try{const n=new URLSearchParams(window.location.search).entries();for(var\[t,e\]of n)if(t.startsWith("docusaurus-data-")){var a=t.replace("docusaurus-data-","data-");document.documentElement.setAttribute(a,e)}}catch(t){}}()
[Skip to main content](https://developers.binance.com/docs/derivatives/usds-margined-futures/general-info)
Derivative Trading API provide REST and WebSocket APIs to suit your derivative trading needs.
File diff suppressed because it is too large Load Diff
@@ -1,12 +0,0 @@
---
title: "New Future Account Transfer | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api"
fetched_at: "2026-01-27T05:28:00.545Z"
---
!function(){function t(t){document.documentElement.setAttribute("data-theme",t)}var e=function(){try{return new URLSearchParams(window.location.search).get("docusaurus-theme")}catch(t){}}()||function(){try{return window.localStorage.getItem("theme")}catch(t){}}();t(null!==e?e:"light")}(),function(){try{const n=new URLSearchParams(window.location.search).entries();for(var\[t,e\]of n)if(t.startsWith("docusaurus-data-")){var a=t.replace("docusaurus-data-","data-");document.documentElement.setAttribute(a,e)}}catch(t){}}()
[Skip to main content](https://developers.binance.com/docs/derivatives/usds-margined-futures/general-info)
# New Future Account Transfer
Please find details from [here](https://developers.binance.com/docs/wallet/asset/user-universal-transfer).
@@ -1,55 +0,0 @@
---
title: "Account Information | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information"
fetched_at: "2026-01-27T05:28:00.542Z"
---
# Account Information (USER\_DATA)
## API Description[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
Get current account information.
## HTTP Request[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
GET `/dapi/v1/account`
## Request Weight[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
**5**
## Request Parameters[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
Name
Type
Mandatory
Description
recvWindow
LONG
NO
timestamp
LONG
YES
> - for One-way Mode user, the "positions" will only show the "BOTH" positions
> - for Hedge Mode user, the "positions" will show "BOTH", "LONG", and "SHORT" positions.
## Response Example[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
```
{ "assets": [ { "asset": "BTC", // asset name "walletBalance": "0.00241969", // total wallet balance "unrealizedProfit": "0.00000000", // unrealized profit or loss "marginBalance": "0.00241969", // margin balance "maintMargin": "0.00000000", // maintenance margin "initialMargin": "0.00000000", // total intial margin required with the latest mark price "positionInitialMargin": "0.00000000", // positions" margin required with the latest mark price "openOrderInitialMargin": "0.00000000", // open orders" intial margin required with the latest mark price "maxWithdrawAmount": "0.00241969", // available amount for transfer out "crossWalletBalance": "0.00241969", // wallet balance for crossed margin "crossUnPnl": "0.00000000", // total unrealized profit or loss of crossed positions "availableBalance": "0.00241969", // available margin balance "updateTime": 1625474304765 //update time } ], "positions": [ { "symbol": "BTCUSD_201225", "positionAmt":"0", // position amount "initialMargin": "0", "maintMargin": "0", "unrealizedProfit": "0.00000000", "positionInitialMargin": "0", "openOrderInitialMargin": "0", "leverage": "125", "isolated": false, "positionSide": "BOTH", // BOTH means that it is the position of One-way Mode "entryPrice": "0.0", "breakEvenPrice": "0.0", // break-even price "maxQty": "50", // maximum quantity of base asset "updateTime": 0 }, { "symbol": "BTCUSD_201225", "positionAmt":"0", "initialMargin": "0", "maintMargin": "0", "unrealizedProfit": "0.00000000", "positionInitialMargin": "0", "openOrderInitialMargin": "0", "leverage": "125", "isolated": false, "positionSide": "LONG", // LONG or SHORT means that it is the position of Hedge Mode "entryPrice": "0.0", "breakEvenPrice": "0.0", // break-even price "maxQty": "50", "updateTime": 0 }, { "symbol": "BTCUSD_201225", "positionAmt":"0", "initialMargin": "0", "maintMargin": "0", "unrealizedProfit": "0.00000000", "positionInitialMargin": "0", "openOrderInitialMargin": "0", "leverage": "125", "isolated": false, "positionSide": "SHORT", // LONG or SHORT means that it is the position of Hedge Mode "entryPrice": "0.0", "breakEvenPrice": "0.0", // break-even price "maxQty": "50", "notionalValue": "0", "updateTime":1627026881327 } ], "canDeposit": true, "canTrade": true, "canWithdraw": true, "feeTier": 2, "updateTime": 0}
```
- [API Description](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
- [HTTP Request](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
- [Request Weight](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
- [Request Parameters](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
- [Response Example](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Account-Information)
@@ -1,52 +0,0 @@
---
title: "Futures Account Balance | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance"
fetched_at: "2026-01-27T05:28:00.720Z"
---
# Futures Account Balance (USER\_DATA)
## API Description[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
Check futures account balance
## HTTP Request[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
GET `/dapi/v1/balance`
## Request Weight[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
**1**
## Request Parameters[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
Name
Type
Mandatory
Description
recvWindow
LONG
NO
timestamp
LONG
YES
## Response Example[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
```
[ { "accountAlias": "SgsR", // unique account code "asset": "BTC", "balance": "0.00250000", "withdrawAvailable": "0.00250000", "crossWalletBalance": "0.00241969", "crossUnPnl": "0.00000000", "availableBalance": "0.00241969", "updateTime": 1592468353979 }]
```
- [API Description](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
- [HTTP Request](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
- [Request Weight](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
- [Request Parameters](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
- [Response Example](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Futures-Account-Balance)
@@ -1,52 +0,0 @@
---
title: "Get Current Position Mode | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode"
fetched_at: "2026-01-27T05:28:00.641Z"
---
# Get Current Position Mode(USER\_DATA)
## API Description[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
Get user's position mode (Hedge Mode or One-way Mode ) on _**EVERY symbol**_
## HTTP Request[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
GET `/dapi/v1/positionSide/dual`
## Request Weight[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
**30**
## Request Parameters[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
Name
Type
Mandatory
Description
recvWindow
LONG
NO
timestamp
LONG
YES
## Response Example[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
```
{ "dualSidePosition": true // "true": Hedge Mode; "false": One-way Mode}
```
- [API Description](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
- [HTTP Request](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
- [Request Weight](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
- [Request Parameters](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
- [Response Example](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Current-Position-Mode)
@@ -1,71 +0,0 @@
---
title: "Get Download Id For Futures Order History | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History"
fetched_at: "2026-01-27T05:28:00.935Z"
---
# Get Download Id For Futures Order History (USER\_DATA)
## API Description[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
Get Download Id For Futures Order History
## HTTP Request[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
GET `/dapi/v1/order/asyn`
## Request Weight[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
**5**
## Request Parameters[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
Name
Type
Mandatory
Description
startTime
LONG
YES
Timestamp in ms
endTime
LONG
YES
Timestamp in ms
recvWindow
LONG
NO
timestamp
LONG
YES
> - Request Limitation is 10 times per month, shared by front end download page and rest api
> - The time between `startTime` and `endTime` can not be longer than 1 year
## Response Example[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
```
{ "avgCostTimestampOfLast30d":7241837, // Average time taken for data download in the past 30 days "downloadId":"546975389218332672",}
```
- [API Description](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
- [HTTP Request](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
- [Request Weight](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
- [Request Parameters](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
- [Response Example](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Order-History)
@@ -1,71 +0,0 @@
---
title: "Get Download Id For Futures Trade History | Binance Open Platform"
source: "https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History"
fetched_at: "2026-01-27T05:28:00.942Z"
---
# Get Download Id For Futures Trade History (USER\_DATA)
## API Description[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
Get download id for futures trade history
## HTTP Request[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
GET `/dapi/v1/trade/asyn`
## Request Weight[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
**5**
## Request Parameters[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
Name
Type
Mandatory
Description
startTime
LONG
YES
Timestamp in ms
endTime
LONG
YES
Timestamp in ms
recvWindow
LONG
NO
timestamp
LONG
YES
> - Request Limitation is 5 times per month, shared by front end download page and rest api
> - The time between `startTime` and `endTime` can not be longer than 1 year
## Response Example[](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
```
{ "avgCostTimestampOfLast30d":7241837, // Average time taken for data download in the past 30 days "downloadId":"546975389218332672",}
```
- [API Description](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
- [HTTP Request](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
- [Request Weight](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
- [Request Parameters](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)
- [Response Example](https://developers.binance.com/docs/derivatives/coin-margined-futures/account/rest-api/Get-Download-Id-For-Futures-Trade-History)

Some files were not shown because too many files have changed in this diff Show More