Public WebSocket API for Binance SPOT Testnet
General API Information
- 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.
- A
serverShutdownevent will be sent when the server is about to shutdown, resulting in disconnection. Please establish a new connection as soon as possible to prevent interruption. - We support HMAC, RSA, and Ed25519 keys. For more information, please see API Key types.
- Responses are in JSON by default. To receive responses in SBE, refer to the 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 frameevery 20 seconds.- If the WebSocket server does not receive a
pong frameback 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 framesare allowed, but will not prevent disconnection. It is recommended that the payload for these pong frames are empty.
- If the WebSocket server does not receive a
- Data is returned in chronological order, unless noted otherwise.
- Without
startTimeorendTime, returns the most recent items up to the limit. - With
startTime, returns oldest items fromstartTimeup to the limit. - With
endTime, returns most recent items up toendTimeand the limit. - With both, behaves like
startTimebut does not exceedendTime.
- Without
- All timestamps in the JSON responses are in milliseconds in UTC by default. To receive the
information in microseconds, please add the parameter
timeUnit=MICROSECONDortimeUnit=microsecondin 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 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)
- 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, 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 for more details.
Request format
Requests must be sent as JSON in text frames, one request per frame.
Example of request:
Code
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
idis truly arbitrary. You can use UUIDs, sequential IDs, current timestamp, etc. The server does not interpretidin 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
paramsis not significant.
Response format
Responses are returned as JSON in text frames, one response per frame.
Example of successful response:
Code
Example of failed response:
Code
Response fields:
Status codes
Status codes in the status field are the same as in HTTP.
Here are some common status codes that you might encounter:
200indicates a successful response.4XXstatus codes indicate invalid requests; the issue is on your side.400– your request failed, seeerrorfor 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 for more details.409– your request partially failed but also partially succeeded, seeerrorfor details.418– you have been auto-banned for repeated violation of rate limits.429– you have exceeded API request rate limit, please slow down.
5XXstatus 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 for a list of error codes and messages.
Event format
User Data Stream events for non-SBE sessions are sent as JSON in text frames, one event per frame.
Events in SBE sessions will be sent as binary frames.
Please refer to userDataStream.subscribe for details on how to
subscribe to User Data Stream in WebSocket API.
Example of an event:
Code
Event fields:
| Name | Type | Mandatory | Description |
|---|---|---|---|
event | OBJECT | YES | Event payload. See User Data Streams |
subscriptionId | INT | NO | Identifies which subscription the event is coming from. See User Data Stream subscriptions |
Connection events
Server Shutdown
serverShutdown event is sent when the server is about to shut down.
Code
Please establish a new connection as soon as possible to prevent interruption.
Rate limits
Connection limits
There is a limit of 300 connections per attempt every 5 minutes.
The connection is per IP address.
General information on rate limits
- Current API rate limits can be queried using the
exchangeInforequest. - There are multiple rate limit types across multiple intervals.
- Responses can indicate current rate limit status in the optional
rateLimitsfield. - Requests fail with status
429when unfilled order count or request rate limits are violated.
How to interpret rate limits
A response with rate limit status may look like this:
Code
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
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
returnRateLimitsboolean parameter in request.Use
returnRateLimitsparameter to control whether to includerateLimitsfields in response to individual requests.Default request and response:
CodeCodeRequest and response without rate limit status:
CodeCode -
Optional
returnRateLimitsboolean parameter in connection URL.If you wish to omit
rateLimitsfrom all responses by default, usereturnRateLimitsparameter in the query string instead:CodeThis 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": trueparameter.
Note: Your requests are still rate limited if you hide the rateLimits field in responses.
IP 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_WEIGHTrate limit type. - Use the
exchangeInforequest 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
retryAfterfield, 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. retryAfterfield indicates the timestamp when the ban will be lifted.
- Requests from a banned IP address fail with status
- 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:
Code
Failed response indicating that you are banned and the ban will last until epoch 1659146400000:
Code
Unfilled Order Count
- Successfully placed orders update the
ORDERSrate limit type. - Rejected or unsuccessful orders might or might not update the
ORDERSrate 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.
- Use the
account.rateLimits.ordersrequest 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
429include aretryAfterfield, 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:
Code
Request security
- Each method has a security type indicating required API key permissions, shown next to the method name (e.g., Place new order (TRADE)).
- If unspecified, the security type is
NONE. - Except for
NONE, all methods with a security type are consideredSIGNEDrequests (i.e. including asignature), except for listenKey management. - Secure methods require a valid API key to be specified and authenticated.
- API keys can be created on the SPOT Test Network 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
TRADEpermission for trading, while using a separate API key withUSER_DATApermission to monitor your order status. - By default, an API key cannot
TRADE. You need to enable trading in API Management first.
- For example, you can have an API key with
| 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
SIGNEDrequests require an additional parameter:signature, authorizing the request.
Signature Case Sensitivity
- 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), SIGNED request example (RSA), and SIGNED request example (Ed25519) on how to compute signature, depending on which API key type you are using.
Timing security
SIGNEDrequests also require atimestampparameter which should be the current timestamp either in milliseconds or microseconds. (See General API Information)- An additional optional parameter,
recvWindow, specifies for how long the request stays valid and may only be specified in milliseconds.recvWindowsupports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.- If
recvWindowis not sent, it defaults to 5000 milliseconds. - Maximum
recvWindowis 60000 milliseconds.
- Request processing logic is as follows:
Code
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)
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:
Code
Example of a request with a symbol name containing non-ASCII characters:
Code
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:
Code
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
Code
Step 2: Compute the signature
- Use the
secretKeyof your API key as the signing key for the HMAC-SHA-256 algorithm. - Sign the UTF-8 bytes of the signature payload constructed in Step 1.
- 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):
Code
For the second set of example parameters (some non-ASCII characters):
Code
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):
Code
For the second set of example parameters (some non-ASCII characters):
Code
SIGNED request example (RSA)
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:
Code
Example of a request with a symbol name containing non-ASCII characters:
Code
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:
Code
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
Code
Step 2: Compute the signature
- 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.
- 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):
Code
For the second set of example parameters (some non-ASCII characters):
Code
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):
Code
For the second set of example parameters (some non-ASCII characters):
Code
SIGNED Request Example (Ed25519)
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:
Code
Example of a request with a symbol name containing non-ASCII characters:
Code
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:
Code
For the second set of example parameters (some non-ASCII characters), the signature payload should look like this:
Code
Step 2: Compute the signature
- Sign the UTF-8 bytes of your signature payload constructed in Step 1 using the Ed25519 private key.
- 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):
Code
For the second set of example parameters (some non-ASCII characters):
Code
Step 3: Add the signature to request params
For the first set of example parameters (ASCII only):
Code
For the second set of example parameters (some non-ASCII characters):
Code
Here is a sample Python script performing all the steps above:
Code
Session Authentication
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
You can authenticate an already established connection using session authentication requests:
session.logon– authenticate, or change the API key associated with the connectionsession.status– check connection status and the current API keysession.logout– 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:
Code
Authorize ad hoc requests
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.
Data sources
-
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.
Public API requests
General requests
Test connectivity
Code
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:
Code
Check server time
Code
Test connectivity to the WebSocket API and get the current server time.
Weight: 1
Parameters: NONE
Data Source: Memory
Response:
Code
Exchange information
Code
Query current exchange trading rules, rate limits, and symbol information.
Weight: 20
Parameters:
Notes:
-
Only one of
symbol,symbols,permissionsparameters can be specified. -
Without parameters,
exchangeInfodisplays all symbols with["SPOT, "MARGIN", "LEVERAGED"]permissions.- In order to list all active symbols on the exchange, you need to explicitly request all permissions.
-
permissionsaccepts either a list of permissions, or a single permission name. E.g."SPOT".
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:
Code
Query Execution Rules
Code
Weight
| Parameter | Weight |
|---|---|
symbol | 2 |
symbols | 2 for each symbol, capped at a max of 40 |
symbolStatus | 40 |
| None | 40 |
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | No | Query for specified symbol |
symbols | STRING | No | Query for multiple symbols |
symbolStatus | ENUM | No | Query for all symbols with the specified status. Supported values: TRADING, HALT, BREAK |
Note: No combination of multiple parameters is allowed.
Data Source: Memory
Response:
Code
Market data requests
Order book
Code
Get current order book.
Note that this request returns limited market depth.
If you need to continuously monitor order book updates, please consider using WebSocket Streams:
You can use depth request together with <symbol>@depth streams to
maintain a local order book.
Weight: Adjusted based on the limit:
| Limit | 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 |
symbolStatus | ENUM | NO | Filters for symbols that have this tradingStatus.A status mismatch returns error -1220 SYMBOL_DOES_NOT_MATCH_STATUSValid values: TRADING, HALT, BREAK |
Data Source: Memory
Response:
Code
Recent trades
Code
Get recent trades.
If you need access to real-time trading activity, please consider using WebSocket Streams:
Weight: 25
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
limit | INT | NO | Default: 500; Maximum: 1000 |
Data Source: Memory
Response:
Code
Historical trades
Code
Get historical trades.
Weight: 25
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
fromId | INT | NO | Trade ID to begin at |
limit | INT | NO | Default: 500; Maximum: 1000 |
Notes:
- If
fromIdis not specified, the most recent trades are returned.
Data Source: Database
Response:
Code
Historical Block Trades
Code
Get block trades.
Weight: 25
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
fromId | LONG | YES | Block trade ID to fetch from |
limit | LONG | NO | Default: 500; Maximum: 1000 |
Data Source: Database
Response:
Code
Aggregate trades
Code
Get aggregate trades.
An aggregate trade (aggtrade) represents one or more individual trades. Trades that fill at the same time, from the same taker order, with the same price – those trades are collected into an aggregate trade with total quantity of the individual trades.
If you need access to real-time trading activity, please consider using WebSocket Streams:
If you need historical aggregate trade data, please consider using data.binance.vision.
Weight: 4
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
fromId | LONG | NO | Aggregate trade ID to begin at |
startTime | LONG | NO | |
endTime | LONG | NO | |
limit | LONG | NO | Default: 500; Maximum: 1000 |
Notes:
-
If
fromIdis specified, return aggtrades with aggregate trade ID >=fromId.Use
fromIdandlimitto page through all aggtrades. -
If
startTimeand/orendTimeare specified, aggtrades are filtered by execution time (T).fromIdcannot be used together withstartTimeandendTime. -
If no condition is specified, the most recent aggregate trades are returned.
Data Source: Database
Response:
Code
Klines
Code
Get klines (candlestick bars).
Klines are uniquely identified by their open & close time.
If you need access to real-time kline updates, please consider using WebSocket Streams:
If you need historical kline data, please consider using data.binance.vision.
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,endTimeare not specified, 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
- Hours and minutes (e.g.
- If
timeZoneprovided, kline intervals are interpreted in that timezone instead of UTC. - Note that
startTimeandendTimeare always interpreted in UTC, regardless of timeZone.
Data Source: Database
Response:
Code
UI Klines
Code
Get klines (candlestick bars) optimized for presentation.
This request is similar to klines, having the same parameters and response. uiKlines
return modified kline data, optimized for presentation of candlestick charts.
Weight: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
interval | ENUM | YES | See klines |
startTime | LONG | NO | |
endTime | LONG | NO | |
timeZone | STRING | NO | Default: 0 (UTC) |
limit | INT | NO | Default: 500; Maximum: 1000 |
Notes:
- If
startTime,endTimeare not specified, 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
- Hours and minutes (e.g.
- If
timeZoneprovided, kline intervals are interpreted in that timezone instead of UTC. - Note that
startTimeandendTimeare always interpreted in UTC, regardless of timeZone.
Data Source: Database
Response:
Code
Current average price
Code
Get current average price for a symbol.
Weight: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES |
Data Source: Memory
Response:
Code
24hr ticker price change statistics
Code
Get 24-hour rolling window price change statistics.
If you need to continuously monitor trading statistics, please consider using WebSocket Streams:
If you need different window sizes, use the ticker
request.
Weight: Adjusted based on the number of requested symbols:
| Symbols | Weight |
|---|---|
| 1–20 | 2 |
| 21–100 | 40 |
| 101 or more | 80 |
| all symbols | 80 |
Parameters:
Notes:
-
symbolandsymbolscannot be used together. -
If no symbol is specified, returns information about all symbols currently trading on the exchange.
Data Source: Memory
Response:
FULL type, for a single symbol:
Code
MINI type, for a single symbol:
Code
If more than one symbol is requested, response returns an array:
Code
Trading Day Ticker
Code
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:
Notes:
- Supported values for
timeZone:- Hours and minutes (e.g.
-1:00,05:45) - Only hours (e.g.
0,8,4)
- Hours and minutes (e.g.
Data Source: Database
Response: - FULL
With symbol:
Code
With symbols:
Code
Response: - MINI
With symbol:
Code
With symbols:
Code
Rolling window price change statistics
Code
Get rolling window price change statistics with a custom window.
This request is similar to ticker.24hr, but statistics are
computed on demand using the arbitrary window you specify.
Note: Window size precision is limited to 1 minute. While the closeTime is the current time of
the request, openTime always start on a minute boundary. As such, the effective window might be up
to 59999 ms wider than the requested windowSize.
For example, a request for "windowSize": "7d" might result in the following window:
Code
Time of the request – closeTime – is 1660184865291 (August 11, 2022 02:27:45.291). Requested
window size should put the openTime 7 days before that – August 4, 02:27:45.291 – but due to
limited precision it ends up a bit earlier: 1659580020000 (August 4, 2022 02:27:00), exactly at the
start of a minute.
If you need to continuously monitor trading statistics, please consider using WebSocket Streams:
Weight: Adjusted based on the number of requested symbols:
| Symbols | Weight |
|---|---|
| 1–50 | 4 per symbol |
| 51–100 | 200 |
Parameters:
Supported window sizes:
| Unit | windowSize value |
|---|---|
| minutes | 1m, 2m ... 59m |
| hours | 1h, 2h ... 23h |
| days | 1d, 2d ... 7d |
Notes:
-
Either
symbolorsymbolsmust be specified. -
Maximum number of symbols in one request: 200.
-
Window size units cannot be combined. E.g., 1d 2h is not supported.
Data Source: Database
Response:
FULL type, for a single symbol:
Code
MINI type, for a single symbol:
Code
If more than one symbol is requested, response returns an array:
Code
Symbol price ticker
Code
Get the latest market price for a symbol.
If you need access to real-time price updates, please consider using WebSocket Streams:
Weight: Adjusted based on the number of requested symbols:
| Parameter | Weight |
|---|---|
symbol | 2 |
symbols | 4 |
| none | 4 |
Parameters:
Notes:
-
symbolandsymbolscannot be used together. -
If no symbol is specified, returns information about all symbols currently trading on the exchange.
Data Source: Memory
Response:
Code
If more than one symbol is requested, response returns an array:
Code
Symbol order book ticker
Code
Get the current best price and quantity on the order book.
If you need access to real-time order book ticker updates, please consider using WebSocket Streams:
Weight: Adjusted based on the number of requested symbols:
| Parameter | Weight |
|---|---|
symbol | 2 |
symbols | 4 |
| none | 4 |
Parameters:
Notes:
-
symbolandsymbolscannot be used together. -
If no symbol is specified, returns information about all symbols currently trading on the exchange.
Data Source: Memory
Response:
Code
If more than one symbol is requested, response returns an array:
Code
Query Reference Price
Code
Weight: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | Yes |
Data Source: Memory
Response:
If a reference price is set:
Code
If no reference price is set:
Code
If no reference price has ever been set:
Code
Query Reference Price Calculation
Code
Describes how reference price is calculated for a given symbol.
Weight: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | Yes | |
symbolStatus | ENUM | No | Supported values: TRADING, HALT, BREAK |
Data Source: Memory
Response:
If reference price is not being calculated:
Code
If the reference price is being calculated by the matching engine as an arithmetic mean:
Code
If the reference price is being calculated outside the matching engine:
Code
Authentication requests
Note: Only Ed25519 keys are supported for this feature.
Log in with API key (SIGNED)
Code
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:
Code
Query session status
Code
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:
Code
Log out of the session
Code
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:
Code
Trading requests
Place new order (TRADE)
Code
Send in a new order.
This adds 1 order to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.
Weight: 1
Unfilled Order Count: 1
Parameters:
| Name | Type | Mandatory | Description |
| ------------------------- | ------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --- |
| symbol | STRING | YES |
| side | ENUM | YES | BUY or SELL |
| type | ENUM | YES |
| timeInForce | ENUM | NO * |
| price | DECIMAL | NO * |
| quantity | DECIMAL | NO * |
| quoteOrderQty | DECIMAL | NO * |
| newClientOrderId | STRING | NO | Arbitrary unique ID among open orders. Automatically generated if not sent |
| newOrderRespType | ENUM | NO | Select response format: ACK, RESULT, FULL.MARKET and LIMIT orders use FULL by default, other order types default to ACK. |
| stopPrice | DECIMAL | NO * |
| trailingDelta | INT | NO * | See Trailing Stop order FAQ |
| icebergQty | DECIMAL | NO |
| strategyId | LONG | NO | Arbitrary numeric value identifying the order within an order strategy. |
| strategyType | INT | NO | Arbitrary numeric value identifying the order strategy.Values smaller than 1000000 are reserved and cannot be used. |
| selfTradePreventionMode | ENUM | NO | The allowed enums is dependent on what is configured on the symbol. Supported values: STP Modes |
| pegPriceType | ENUM | NO | PRIMARY_PEG or MARKET_PEG See Pegged Orders | |
| pegOffsetValue | INT | NO | Price level to peg the price to (max: 100) See Pegged Orders |
| pegOffsetType | ENUM | NO | Only PRICE_LEVEL is supported See Pegged Orders | |
| 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 |
Certain parameters (*) become mandatory based on the order type:
Supported order types:
Notes on using parameters for Pegged Orders:
- These parameters are allowed for
LIMIT,LIMIT_MAKER,STOP_LOSS_LIMIT,TAKE_PROFIT_LIMITorders. - If
pegPriceTypeis specified,pricebecomes optional. Otherwise, it is still mandatory. pegPriceType=PRIMARY_PEGmeans the primary peg, that is the best price on the same side of the order book as your order.pegPriceType=MARKET_PEGmeans the market peg, that is the best price on the opposite side of the order book from your order.- Use
pegOffsetTypeandpegOffsetValueto request a price level other than the best one. These parameters must be specified together.
Available timeInForce options, setting how long the order should be active before expiration:
| TIF | Description |
|---|---|
GTC | Good 'til Canceled – the order will remain on the book until you cancel it, or the order is completely filled. |
IOC | Immediate or Cancel – the order will be filled for as much as possible, the unfilled quantity immediately expires. |
FOK | Fill or Kill – the order will expire unless it cannot be immediately filled for the entire quantity. |
Notes:
-
newClientOrderIdspecifiesclientOrderIdvalue for the order.A new order with the same
clientOrderIdis accepted only when the previous one is filled or expired. -
Any
LIMITorLIMIT_MAKERorder can be made into an iceberg order by specifying theicebergQty.An order with an
icebergQtymust havetimeInForceset toGTC. -
Trigger order price rules for
STOP_LOSS/TAKE_PROFITorders:stopPricemust be above market price:STOP_LOSS BUY,TAKE_PROFIT SELLstopPricemust be below market price:STOP_LOSS SELL,TAKE_PROFIT BUY
-
MARKETorders usingquoteOrderQtyfollowLOT_SIZEfilter rules.The order will execute a quantity that has notional value as close as possible to requested
quoteOrderQty.
Data Source: Matching Engine
Response:
Response format is selected by using the newOrderRespType parameter.
ACK response type:
Code
RESULT response type:
Code
FULL response type:
Code
Conditional fields in Order Responses
There are fields in the order responses (e.g. order placement, order query, order cancellation) that appear only if certain conditions are met.
These fields can apply to Order lists.
The fields are listed below:
| Field | Description | Visibility conditions | Examples |
|---|---|---|---|
icebergQty | Quantity for the iceberg order | Appears only if the parameter icebergQty was sent in the request. | "icebergQty": "0.00000000" |
preventedMatchId | When used in combination with symbol, can be used to query a prevented match. | Appears only if the order expired due to STP. | "preventedMatchId": 0 |
preventedQuantity | Order quantity that expired due to STP | Appears only if the order expired due to STP. | "preventedQuantity": "1.200000" |
stopPrice | Price when the algorithmic order will be triggered | Appears for STOP_LOSS. TAKE_PROFIT, STOP_LOSS_LIMIT and TAKE_PROFIT_LIMIT orders. | "stopPrice": "23500.00000000" |
strategyId | Can be used to label an order that's part of an order strategy. | Appears if the parameter was populated in the request. | "strategyId": 37463720 |
strategyType | Can be used to label an order that is using an order strategy. | Appears if the parameter was populated in the request. | "strategyType": 1000000 |
trailingDelta | Delta price change required before order activation | Appears for Trailing Stop Orders. | "trailingDelta": 10 |
trailingTime | Time when the trailing order is now active and tracking price changes | Appears only for Trailing Stop Orders. | "trailingTime": -1 |
usedSor | Field that determines whether order used SOR | Appears when placing orders using SOR | "usedSor": true |
workingFloor | Field that determines whether the order is being filled by the SOR or by the order book the order was submitted to. | Appears when placing orders using SOR | "workingFloor": "SOR" |
pegPriceType | Price peg type | Only for pegged orders | "pegPriceType": "PRIMARY_PEG" |
pegOffsetType | Price peg offset type | Only for pegged orders, if requested | "pegOffsetType": "PRICE_LEVEL" |
pegOffsetValue | Price peg offset value | Only for pegged orders, if requested | "pegOffsetValue": 5 |
peggedPrice | Current price order is pegged at | Only for pegged orders, once determined | "peggedPrice": "87523.83710000" |
expiryReason | Cause of the order’s expiration | When an order has expired | “expiryReason”: “INSUFFICIENT_LIQUIDITY” |
Test new order (TRADE)
Code
Test order placement.
Validates new order parameters and verifies your signature but does not send the order into the matching engine.
Weight:
| Condition | Request Weight |
|---|---|
Without computeCommissionRates | 1 |
With computeCommissionRates | 20 |
Parameters:
In addition to all parameters accepted by order.place, the following
optional parameters are also accepted:
| Name | Type | Mandatory | Description |
|---|---|---|---|
computeCommissionRates | BOOLEAN | NO | Default: false See Commissions FAQ to learn more. |
Data Source: Memory
Response:
Without computeCommissionRates:
Code
With computeCommissionRates:
Code
Cancel order (TRADE)
Code
Cancel an active order.
Weight: 1
Parameters:
Notes:
-
If both
orderIdandorigClientOrderIdparameters are provided, theorderIdis searched first, then theorigClientOrderIdfrom that result is checked against that order. If both conditions are not met the request will be rejected. -
newClientOrderIdwill replaceclientOrderIdof the canceled order, freeing it up for new orders. -
If you cancel an order that is a part of an order list, the entire order list is canceled.
-
The performance for canceling an order (single cancel or as part of a cancel-replace) is always better when only
orderIdis sent. SendingorigClientOrderIdor bothorderId+origClientOrderIdwill be slower.
Data Source: Matching Engine
Response:
When an individual order is canceled:
Code
When an order list is canceled:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Regarding cancelRestrictions
- If the
cancelRestrictionsvalue is not any of the supported values, the error will be:
Code
- If the order did not pass the conditions for
cancelRestrictions, the error will be:
Code
Cancel and replace order (TRADE)
Code
- Cancel an existing order and immediately place a new order instead of the canceled one.
- A new order that was not attempted (i.e. when
newOrderResult: NOT_ATTEMPTED), will still increase the unfilled order count by 1. - You can only cancel an individual order from an orderList using this method, but the result is the same as canceling the entire orderList.
Weight: 1
Unfilled Order Count: 1
Parameters:
Similar to the order.place request, additional mandatory parameters (*)
are determined by the new order type.
Available cancelReplaceMode options:
STOP_ON_FAILURE– if cancellation request fails, new order placement will not be attempted.ALLOW_FAILURE– new order placement will be attempted even if the cancel request fails.
Notes:
-
If both
cancelOrderIdandcancelOrigClientOrderIdparameters are provided, thecancelOrderIdis searched first, then thecancelOrigClientOrderIdfrom that result is checked against that order. If both conditions are not met the request will be rejected. -
cancelNewClientOrderIdwill replaceclientOrderIdof the canceled order, freeing it up for new orders. -
newClientOrderIdspecifiesclientOrderIdvalue for the placed order.A new order with the same
clientOrderIdis accepted only when the previous one is filled or expired.The new order can reuse old
clientOrderIdof the canceled order. -
This cancel-replace operation is not transactional.
If one operation succeeds but the other one fails, the successful operation is still executed.
For example, in
STOP_ON_FAILUREmode, if the new order placement fails, the old order is still canceled. -
Filters and order count limits are evaluated before cancellation and order placement occurs.
-
If new order placement is not attempted, your order count is still incremented.
-
Like
order.cancel, if you cancel an individual order from an order list, the entire order list is canceled. -
The performance for canceling an order (single cancel or as part of a cancel-replace) is always better when only
orderIdis sent. SendingorigClientOrderIdor bothorderId+origClientOrderIdwill be slower.
Data Source: Matching Engine
Response:
If both cancel and placement succeed, you get the following response with "status": 200:
Code
In STOP_ON_FAILURE mode, failed order cancellation prevents new order from being placed and
returns the following response with "status": 400:
Code
If cancel-replace mode allows failure and one of the operations fails, you get a response with
"status": 409, and the "data" field detailing which operation succeeded, which failed, and why:
Code
Code
If both operations fail, response will have "status": 400:
Code
If orderRateLimitExceededMode is DO_NOTHING regardless of cancelReplaceMode, and you have
exceeded your unfilled order count, you will get status 429 with the following error:
Code
If orderRateLimitExceededMode is CANCEL_ONLY regardless of cancelReplaceMode, and you have
exceeded your unfilled order count, you will get status 409 with the following error:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Order Amend Keep Priority (TRADE)
Code
Reduce the quantity of an existing open order.
This adds 0 orders to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.
Read Order Amend Keep Priority FAQ to learn more.
Weight: 4
Unfilled Order Count: 0
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
| symbol | STRING | YES | |
| orderId | LONG | NO* | orderId or origClientOrderId must be sent |
| origClientOrderId | STRING | NO* | orderId or origClientOrderId must be sent |
| newClientOrderId | STRING | NO* | The new client order ID for the order after being amended. If not sent, one will be randomly generated. It is possible to reuse the current clientOrderId by sending it as the newClientOrderId. |
| newQty | DECIMAL | YES | newQty must be greater than 0 and less than the order's quantity. |
| 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: Matching Engine
Response:
Response for a single order:
Code
Response for an order which is part of an Order list:
Code
Note: The payloads above do not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Cancel open orders (TRADE)
Code
Cancel all open orders on a symbol. This includes orders that are part of an order list.
Weight: 1
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
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: Matching Engine
Response:
Cancellation reports for orders and order lists have the same format as in
order.cancel.
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Order lists
Place new Order list - OCO (TRADE)
Code
Send in an one-cancels-the-other (OCO) pair, where activation of one order immediately cancels the other.
- An OCO has 2 orders called the above order and below order.
- One of the orders must be a
LIMIT_MAKER/TAKE_PROFIT/TAKE_PROFIT_LIMITorder and the other must beSTOP_LOSSorSTOP_LOSS_LIMITorder. - Price restrictions:
- If the OCO is on the
SELLside:LIMIT_MAKER/TAKE_PROFIT_LIMITprice> Last Traded Price >STOP_LOSS/STOP_LOSS_LIMITstopPriceTAKE_PROFIT stopPrice> Last Traded Price >STOP_LOSS/STOP_LOSS_LIMIT stopPrice
- If the OCO is on the
BUYside:LIMIT_MAKERprice< Last Traded Price <STOP_LOSS/STOP_LOSS_LIMITstopPriceTAKE_PROFIT stopPrice> Last Traded Price >STOP_LOSS/STOP_LOSS_LIMIT stopPrice
- If the OCO is on the
- OCOs add 2 orders to the
EXCHANGE_MAX_ORDERSfilter andMAX_NUM_ORDERSfilter.
Weight: 1
Unfilled Order Count: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
listClientOrderId | STRING | NO | Arbitrary unique ID among open order lists. Automatically generated if not sent. A new order list with the same listClientOrderId is accepted only when the previous one is filled or completely expired. listClientOrderId is distinct from the aboveClientOrderId and the belowCLientOrderId. |
side | ENUM | YES | BUY or SELL |
quantity | DECIMAL | YES | Quantity for both orders of the order list. |
aboveType | ENUM | YES | Supported values: STOP_LOSS_LIMIT, STOP_LOSS, LIMIT_MAKER, TAKE_PROFIT, TAKE_PROFIT_LIMIT |
aboveClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the above order. Automatically generated if not sent |
aboveIcebergQty | LONG | NO | Note that this can only be used if aboveTimeInForce is GTC. |
abovePrice | DECIMAL | NO | Can be used if aboveType is STOP_LOSS_LIMIT , LIMIT_MAKER, or TAKE_PROFIT_LIMIT to specify the limit price. |
aboveStopPrice | DECIMAL | NO | Can be used if aboveType is STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, TAKE_PROFIT_LIMIT. Either aboveStopPrice or aboveTrailingDelta or both, must be specified. |
aboveTrailingDelta | LONG | NO | See Trailing Stop order FAQ. |
aboveTimeInForce | ENUM | NO | Required if aboveType is STOP_LOSS_LIMIT or TAKE_PROFIT_LIMIT. |
aboveStrategyId | LONG | NO | Arbitrary numeric value identifying the above order within an order strategy. |
aboveStrategyType | INT | NO | Arbitrary numeric value identifying the above order strategy. Values smaller than 1000000 are reserved and cannot be used. |
abovePegPriceType | ENUM | NO | See Pegged Orders |
abovePegOffsetType | ENUM | NO | |
abovePegOffsetValue | INT | NO | |
belowType | ENUM | YES | Supported values: STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT,TAKE_PROFIT_LIMIT |
belowClientOrderId | STRING | NO | |
belowIcebergQty | LONG | NO | Note that this can only be used if belowTimeInForce is GTC. |
belowPrice | DECIMAL | NO | Can be used if belowType is STOP_LOSS_LIMIT , LIMIT_MAKER, or TAKE_PROFIT_LIMIT to specify the limit price. |
belowStopPrice | DECIMAL | NO | Can be used if belowType is STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT or TAKE_PROFIT_LIMIT. Either belowStopPrice or belowTrailingDelta or both, must be specified. |
belowTrailingDelta | LONG | NO | See Trailing Stop order FAQ. |
belowTimeInForce | ENUM | NO | Required if belowType is STOP_LOSS_LIMIT or TAKE_PROFIT_LIMIT |
belowStrategyId | LONG | NO | Arbitrary numeric value identifying the below order within an order strategy. |
belowStrategyType | INT | NO | Arbitrary numeric value identifying the below order strategy. Values smaller than 1000000 are reserved and cannot be used. |
belowPegPriceType | ENUM | NO | See Pegged Orders |
belowPegOffsetType | ENUM | NO | |
belowPegOffsetValue | INT | NO | |
newOrderRespType | ENUM | NO | Select response format: ACK, RESULT, FULL |
selfTradePreventionMode | ENUM | NO | The allowed enums is dependent on what is configured on the symbol. The possible supported values are: STP Modes. |
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. |
timestamp | LONG | YES | |
signature | STRING | YES |
Data Source: Matching Engine
Response:
Response format for orderReports is selected using the newOrderRespType parameter. The following
example is for RESULT response type. See order.place for more
examples.
Code
Place new Order list - OTO (TRADE)
Code
Places an OTO.
- An OTO (One-Triggers-the-Other) is an order list comprised of 2 orders.
- The first order is called the working order and must be
LIMITorLIMIT_MAKER. Initially, only the working order goes on the order book. - The second order is called the pending order. It can be any order type except for
MARKETorders using parameterquoteOrderQty. The pending order is only placed on the order book when the working order gets fully filled. - If either the working order or the pending order is cancelled individually, the other order in the order list will also be canceled or expired.
- When the order list is placed, if the working order gets immediately fully filled, the
placement response will show the working order as
FILLEDbut the pending order will still appear asPENDING_NEW. You need to query the status of the pending order again to see its updated status. - OTOs add 2 orders to the
EXCHANGE_MAX_NUM_ORDERSfilter andMAX_NUM_ORDERSfilter.
Weight: 1
Unfilled Order Count: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
listClientOrderId | STRING | NO | Arbitrary unique ID among open order lists. Automatically generated if not sent. A new order list with the same listClientOrderId is accepted only when the previous one is filled or completely expired. listClientOrderId is distinct from the workingClientOrderId and the pendingClientOrderId. |
newOrderRespType | ENUM | NO | Format of the JSON response. Supported values: Order Response Type |
selfTradePreventionMode | ENUM | NO | The allowed values are dependent on what is configured on the symbol. Supported values: STP Modes |
workingType | ENUM | YES | Supported values: LIMIT,LIMIT_MAKER |
workingSide | ENUM | YES | Supported values: Order side |
workingClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the working order. Automatically generated if not sent. |
workingPrice | DECIMAL | YES | |
workingQuantity | DECIMAL | YES | Sets the quantity for the working order. |
workingIcebergQty | DECIMAL | NO | This can only be used if workingTimeInForce is GTC, or if workingType is LIMIT_MAKER. |
workingTimeInForce | ENUM | NO | Supported values: Time In Force |
workingStrategyId | LONG | NO | Arbitrary numeric value identifying the working order within an order strategy. |
workingStrategyType | INT | NO | Arbitrary numeric value identifying the working order strategy. Values smaller than 1000000 are reserved and cannot be used. |
workingPegPriceType | ENUM | NO | See Pegged Orders |
workingPegOffsetType | ENUM | NO | |
workingPegOffsetValue | INT | NO | |
pendingType | ENUM | YES | Supported values: Order types. Note that MARKET orders using quoteOrderQty are not supported. |
pendingSide | ENUM | YES | Supported values: Order side |
pendingClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the pending order. Automatically generated if not sent. |
pendingPrice | DECIMAL | NO | |
pendingStopPrice | DECIMAL | NO | |
pendingTrailingDelta | DECIMAL | NO | |
pendingQuantity | DECIMAL | YES | Sets the quantity for the pending order. |
pendingIcebergQty | DECIMAL | NO | This can only be used if pendingTimeInForce is GTC, or if pendingType is LIMIT_MAKER. |
pendingTimeInForce | ENUM | NO | Supported values: Time In Force |
pendingStrategyId | LONG | NO | Arbitrary numeric value identifying the pending order within an order strategy. |
pendingStrategyType | INT | NO | Arbitrary numeric value identifying the pending order strategy. Values smaller than 1000000 are reserved and cannot be used. |
pendingPegOffsetType | ENUM | NO | See Pegged Orders |
pendingPegPriceType | ENUM | NO | |
pendingPegOffsetValue | INT | 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 | |
signature | STRING | YES |
Mandatory parameters based on pendingType or workingType
Depending on the pendingType or workingType, some optional parameters will become mandatory.
| Type | Additional mandatory parameters | Additional information |
|---|---|---|
workingType = LIMIT | workingTimeInForce | |
pendingType = LIMIT | pendingPrice, pendingTimeInForce | |
pendingType = STOP_LOSS or TAKE_PROFIT | pendingStopPrice and/or pendingTrailingDelta | |
pendingType =STOP_LOSS_LIMIT or TAKE_PROFIT_LIMIT | pendingPrice, pendingStopPrice and/or pendingTrailingDelta, pendingTimeInForce |
Data Source:
Matching Engine
Response:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Place new Order list - OTOCO (TRADE)
Code
Place an OTOCO.
- An OTOCO (One-Triggers-One-Cancels-the-Other) is an order list comprised of 3 orders.
- The first order is called the working order and must be
LIMITorLIMIT_MAKER. Initially, only the working order goes on the order book.- The behavior of the working order is the same as the OTO.
- OTOCO has 2 pending orders (pending above and pending below), forming an OCO pair. The pending
orders are only placed on the order book when the working order gets fully filled.
- The rules of the pending above and pending below follow the same rules as the Order list OCO.
- OTOCOs add 3 orders to the
EXCHANGE_MAX_NUM_ORDERSfilter andMAX_NUM_ORDERSfilter.
Weight: 1
Unfilled Order Count: 3
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
listClientOrderId | STRING | NO | Arbitrary unique ID among open order lists. Automatically generated if not sent. A new order list with the same listClientOrderId is accepted only when the previous one is filled or completely expired. listClientOrderId is distinct from the workingClientOrderId, pendingAboveClientOrderId, and the pendingBelowClientOrderId. |
newOrderRespType | ENUM | NO | Format of the JSON response. Supported values: Order Response Type |
selfTradePreventionMode | ENUM | NO | The allowed values are dependent on what is configured on the symbol. Supported values: STP Modes |
workingType | ENUM | YES | Supported values: LIMIT, LIMIT_MAKER |
workingSide | ENUM | YES | Supported values: Order Side |
workingClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the working order. Automatically generated if not sent. |
workingPrice | DECIMAL | YES | |
workingQuantity | DECIMAL | YES | |
workingIcebergQty | DECIMAL | NO | This can only be used if workingTimeInForce is GTC, or if workingType is LIMIT_MAKER. |
workingTimeInForce | ENUM | NO | Supported values: Time In Force |
workingStrategyId | LONG | NO | Arbitrary numeric value identifying the working order within an order strategy. |
workingStrategyType | INT | NO | Arbitrary numeric value identifying the working order strategy. Values smaller than 1000000 are reserved and cannot be used. |
workingPegPriceType | ENUM | NO | See Pegged Orders |
workingPegOffsetType | ENUM | NO | |
workingPegOffsetValue | INT | NO | |
pendingSide | ENUM | YES | Supported values: Order Side |
pendingQuantity | DECIMAL | YES | |
pendingAboveType | ENUM | YES | Supported values: STOP_LOSS_LIMIT, STOP_LOSS, LIMIT_MAKER, TAKE_PROFIT, TAKE_PROFIT_LIMIT |
pendingAboveClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the pending above order. Automatically generated if not sent. |
pendingAbovePrice | DECIMAL | NO | Can be used if pendingAboveType is STOP_LOSS_LIMIT , LIMIT_MAKER, or TAKE_PROFIT_LIMIT to specify the limit price. |
pendingAboveStopPrice | DECIMAL | NO | Can be used if pendingAboveType is STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, TAKE_PROFIT_LIMIT |
pendingAboveTrailingDelta | DECIMAL | NO | See Trailing Stop FAQ |
pendingAboveIcebergQty | DECIMAL | NO | This can only be used if pendingAboveTimeInForce is GTC or if pendingAboveType is LIMIT_MAKER. |
pendingAboveTimeInForce | ENUM | NO | |
pendingAboveStrategyId | LONG | NO | Arbitrary numeric value identifying the pending above order within an order strategy. |
pendingAboveStrategyType | INT | NO | Arbitrary numeric value identifying the pending above order strategy. Values smaller than 1000000 are reserved and cannot be used. |
pendingAbovePegPriceType | ENUM | NO | See Pegged Orders |
pendingAbovePegOffsetType | ENUM | NO | |
pendingAbovePegOffsetValue | INT | NO | |
pendingBelowType | ENUM | NO | Supported values: STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT,TAKE_PROFIT_LIMIT |
pendingBelowClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the pending below order. Automatically generated if not sent. |
pendingBelowPrice | DECIMAL | NO | Can be used if pendingBelowType is STOP_LOSS_LIMIT or TAKE_PROFIT_LIMIT to specify the limit price. |
pendingBelowStopPrice | DECIMAL | NO | Can be used if pendingBelowType is STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT or TAKE_PROFIT_LIMIT. Either pendingBelowStopPrice or pendingBelowTrailingDelta or both, must be specified. |
pendingBelowTrailingDelta | DECIMAL | NO | |
pendingBelowIcebergQty | DECIMAL | NO | This can only be used if pendingBelowTimeInForce is GTC, or if pendingBelowType is LIMIT_MAKER. |
pendingBelowTimeInForce | ENUM | NO | Supported values: Time In Force |
pendingBelowStrategyId | LONG | NO | Arbitrary numeric value identifying the pending below order within an order strategy. |
pendingBelowStrategyType | INT | NO | Arbitrary numeric value identifying the pending below order strategy. Values smaller than 1000000 are reserved and cannot be used. |
pendingBelowPegPriceType | ENUM | NO | See Pegged Orders |
pendingBelowPegOffsetType | ENUM | NO | |
pendingBelowPegOffsetValue | INT | 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 | |
signature | STRING | YES |
Mandatory parameters based on pendingAboveType, pendingBelowType or workingType
Depending on the pendingAboveType/pendingBelowType or workingType, some optional parameters
will become mandatory.
| Type | Additional mandatory parameters | Additional information |
|---|---|---|
workingType = LIMIT | workingTimeInForce | |
pendingAboveType= LIMIT_MAKER | pendingAbovePrice | |
pendingAboveType = STOP_LOSS/TAKE_PROFIT | pendingAboveStopPrice and/or pendingAboveTrailingDelta | |
pendingAboveType=STOP_LOSS_LIMIT/TAKE_PROFIT_LIMIT | pendingAbovePrice, pendingAboveStopPrice and/or pendingAboveTrailingDelta, pendingAboveTimeInForce | |
pendingBelowType= LIMIT_MAKER | pendingBelowPrice | |
pendingBelowType= STOP_LOSS/TAKE_PROFIT | pendingBelowStopPrice and/or pendingBelowTrailingDelta | |
pendingBelowType=STOP_LOSS_LIMIT/TAKE_PROFIT_LIMIT | pendingBelowPrice, pendingBelowStopPrice and/or pendingBelowTrailingDelta, pendingBelowTimeInForce |
Data Source: Matching Engine
Response:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
OPO (TRADE)
Code
Place an OPO.
- OPOs add 2 orders to the EXCHANGE_MAX_NUM_ORDERS filter and MAX_NUM_ORDERS filter.
Weight: 1
Unfilled Order Count: 2
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
listClientOrderId | STRING | NO | Arbitrary unique ID among open order lists. Automatically generated if not sent. A new order list with the same listClientOrderId is accepted only when the previous one is filled or completely expired. listClientOrderId is distinct from the workingClientOrderId and the pendingClientOrderId. |
newOrderRespType | ENUM | NO | Format of the JSON response. Supported values: Order Response Type |
selfTradePreventionMode | ENUM | NO | The allowed values are dependent on what is configured on the symbol. Supported values: STP Modes |
workingType | ENUM | YES | Supported values: LIMIT,LIMIT_MAKER |
workingSide | ENUM | YES | Supported values: Order Side |
workingClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the working order. Automatically generated if not sent. |
workingPrice | DECIMAL | YES | |
workingQuantity | DECIMAL | YES | Sets the quantity for the working order. |
workingIcebergQty | DECIMAL | NO | This can only be used if workingTimeInForce is GTC, or if workingType is LIMIT_MAKER. |
workingTimeInForce | ENUM | NO | Supported values: Time In Force |
workingStrategyId | LONG | NO | Arbitrary numeric value identifying the working order within an order strategy. |
workingStrategyType | INT | NO | Arbitrary numeric value identifying the working order strategy. Values smaller than 1000000 are reserved and cannot be used. |
workingPegPriceType | ENUM | NO | See Pegged Orders |
workingPegOffsetType | ENUM | NO | |
workingPegOffsetValue | INT | NO | |
pendingType | ENUM | YES | Supported values: Order Types Note that MARKET orders using quoteOrderQty are not supported. |
pendingSide | ENUM | YES | Supported values: Order Side |
pendingClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the pending order. Automatically generated if not sent. |
pendingPrice | DECIMAL | NO | |
pendingStopPrice | DECIMAL | NO | |
pendingTrailingDelta | DECIMAL | NO | |
pendingIcebergQty | DECIMAL | NO | This can only be used if pendingTimeInForce is GTC or if pendingType is LIMIT_MAKER. |
pendingTimeInForce | ENUM | NO | Supported values: Time In Force |
pendingStrategyId | LONG | NO | Arbitrary numeric value identifying the pending order within an order strategy. |
pendingStrategyType | INT | NO | Arbitrary numeric value identifying the pending order strategy. Values smaller than 1000000 are reserved and cannot be used. |
pendingPegPriceType | ENUM | NO | See Pegged Orders |
pendingPegOffsetType | ENUM | NO | |
pendingPegOffsetValue | INT | 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 |
Data Source: Matching Engine
Response:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
OPOCO (TRADE)
Code
Place an OPOCO.
Weight: 1
Unfilled Order Count: 3
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
listClientOrderId | STRING | NO | Arbitrary unique ID among open order lists. Automatically generated if not sent. A new order list with the same listClientOrderId is accepted only when the previous one is filled or completely expired. listClientOrderId is distinct from the workingClientOrderId, pendingAboveClientOrderId, and the pendingBelowClientOrderId. |
newOrderRespType | ENUM | NO | Format of the JSON response. Supported values: Order Response Type |
selfTradePreventionMode | ENUM | NO | The allowed values are dependent on what is configured on the symbol. Supported values: STP Modes |
workingType | ENUM | YES | Supported values: LIMIT, LIMIT_MAKER |
workingSide | ENUM | YES | Supported values: Order side |
workingClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the working order. Automatically generated if not sent. |
workingPrice | DECIMAL | YES | |
workingQuantity | DECIMAL | YES | |
workingIcebergQty | DECIMAL | NO | This can only be used if workingTimeInForce is GTC, or if workingType is LIMIT_MAKER. |
workingTimeInForce | ENUM | NO | Supported values: Time In Force |
workingStrategyId | LONG | NO | Arbitrary numeric value identifying the working order within an order strategy. |
workingStrategyType | INT | NO | Arbitrary numeric value identifying the working order strategy. Values smaller than 1000000 are reserved and cannot be used. |
workingPegPriceType | ENUM | NO | See Pegged Orders |
workingPegOffsetType | ENUM | NO | |
workingPegOffsetValue | INT | NO | |
pendingSide | ENUM | YES | Supported values: Order side |
pendingAboveType | ENUM | YES | Supported values: STOP_LOSS_LIMIT, STOP_LOSS, LIMIT_MAKER, TAKE_PROFIT, TAKE_PROFIT_LIMIT |
pendingAboveClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the pending above order. Automatically generated if not sent. |
pendingAbovePrice | DECIMAL | NO | Can be used if pendingAboveType is STOP_LOSS_LIMIT , LIMIT_MAKER, or TAKE_PROFIT_LIMIT to specify the limit price. |
pendingAboveStopPrice | DECIMAL | NO | Can be used if pendingAboveType is STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, TAKE_PROFIT_LIMIT |
pendingAboveTrailingDelta | DECIMAL | NO | See Trailing Stop FAQ |
pendingAboveIcebergQty | DECIMAL | NO | This can only be used if pendingAboveTimeInForce is GTC or if pendingAboveType is LIMIT_MAKER. |
pendingAboveTimeInForce | ENUM | NO | |
pendingAboveStrategyId | LONG | NO | Arbitrary numeric value identifying the pending above order within an order strategy. |
pendingAboveStrategyType | INT | NO | Arbitrary numeric value identifying the pending above order strategy. Values smaller than 1000000 are reserved and cannot be used. |
pendingAbovePegPriceType | ENUM | NO | See Pegged Orders |
pendingAbovePegOffsetType | ENUM | NO | |
pendingAbovePegOffsetValue | INT | NO | |
pendingBelowType | ENUM | NO | Supported values: STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT,TAKE_PROFIT_LIMIT |
pendingBelowClientOrderId | STRING | NO | Arbitrary unique ID among open orders for the pending below order. Automatically generated if not sent. |
pendingBelowPrice | DECIMAL | NO | Can be used if pendingBelowType is STOP_LOSS_LIMIT or TAKE_PROFIT_LIMIT to specify limit price |
pendingBelowStopPrice | DECIMAL | NO | Can be used if pendingBelowType is STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT or TAKE_PROFIT_LIMIT. Either pendingBelowStopPrice or pendingBelowTrailingDelta or both, must be specified. |
pendingBelowTrailingDelta | DECIMAL | NO | |
pendingBelowIcebergQty | DECIMAL | NO | This can only be used if pendingBelowTimeInForce is GTC, or if pendingBelowType is LIMIT_MAKER. |
pendingBelowTimeInForce | ENUM | NO | Supported values: Time In Force |
pendingBelowStrategyId | LONG | NO | Arbitrary numeric value identifying the pending below order within an order strategy. |
pendingBelowStrategyType | INT | NO | Arbitrary numeric value identifying the pending below order strategy. Values smaller than 1000000 are reserved and cannot be used. |
pendingBelowPegPriceType | ENUM | NO | See Pegged Orders |
pendingBelowPegOffsetType | ENUM | NO | |
pendingBelowPegOffsetValue | INT | 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 |
Data Source: Matching Engine
Response:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Cancel Order list (TRADE)
Code
Cancel an active order list.
Weight: 1
Parameters:
Notes:
-
If both
orderListIdandlistClientOrderIdparameters are provided, theorderListIdis searched first, then thelistClientOrderIdfrom that result is checked against that order. If both conditions are not met the request will be rejected. -
Canceling an individual order with
order.cancelwill cancel the entire order list as well.
Data Source: Matching Engine
Response:
Code
SOR
Place new order using SOR (TRADE)
Code
Places an order using smart order routing (SOR).
This adds 1 order to the EXCHANGE_MAX_ORDERS filter and the MAX_NUM_ORDERS filter.
Read SOR FAQ to learn more.
Weight: 1
Unfilled Order Count: 1
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
side | ENUM | YES | BUY or SELL |
type | ENUM | YES | |
timeInForce | ENUM | NO | Applicable only to LIMIT order type |
price | DECIMAL | NO | Applicable only to LIMIT order type |
quantity | DECIMAL | YES | |
newClientOrderId | STRING | NO | Arbitrary unique ID among open orders. Automatically generated if not sent |
newOrderRespType | ENUM | NO | Select response format: ACK, RESULT, FULL.MARKET and LIMIT orders use FULL by default. |
icebergQty | DECIMAL | NO | |
strategyId | LONG | NO | Arbitrary numeric value identifying the order within an order strategy. |
strategyType | INT | NO | Arbitrary numeric value identifying the order strategy.Values smaller than 1000000 are reserved and cannot be used. |
selfTradePreventionMode | ENUM | NO | The allowed enums is dependent on what is configured on the symbol. The possible supported values are: STP Modes. |
apiKey | STRING | YES | |
timestamp | LONG | 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 |
Note: sor.order.place only supports LIMIT and MARKET orders. quoteOrderQty is not
supported.
Data Source: Matching Engine
Response:
Code
Test new order using SOR (TRADE)
Code
Test new order creation and signature/recvWindow using smart order routing (SOR). Creates and validates a new order but does not send it into the matching engine.
Weight:
| Condition | Request Weight |
|---|---|
Without computeCommissionRates | 1 |
With computeCommissionRates | 20 |
Parameters:
In addition to all parameters accepted by sor.order.place, the
following optional parameters are also accepted:
| Name | Type | Mandatory | Description |
|---|---|---|---|
computeCommissionRates | BOOLEAN | NO | Default: false |
Data Source: Memory
Response:
Without computeCommissionRates:
Code
With computeCommissionRates:
Code
Account requests
Account information (USER_DATA)
Code
Query information about your account.
Weight: 20
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
apiKey | STRING | YES | |
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. |
signature | STRING | YES | |
timestamp | LONG | YES |
Data Source: Memory => Database
Response:
Code
Query order (USER_DATA)
Code
Check execution status of an order.
Weight: 4
Parameters:
Notes:
-
If both
orderIdandorigClientOrderIdare provided, theorderIdis searched first, then theorigClientOrderIdfrom that result is checked against that order. If both conditions are not met the request will be rejected. -
For some historical orders the
cummulativeQuoteQtyresponse field may be negative, meaning the data is not available at this time.
Data Source: Memory => Database
Response:
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Current open orders (USER_DATA)
Code
Query execution status of all open orders.
If you need to continuously monitor order status updates, please consider using WebSocket Streams:
userDataStream.subscribeif on an authenticated sessionuserDataStream.subscribe.signatureif subscribing through signature subscription
Weight: Adjusted based on the number of requested symbols:
| Parameter | Weight |
|---|---|
symbol | 6 |
| none | 80 |
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | NO | If omitted, open orders for all symbols are returned |
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 => Database
Response:
Status reports for open orders are identical to order.status.
Note that some fields are optional and included only for orders that set them.
Open orders are always returned as a flat list. If all symbols are requested, use the symbol field
to tell which symbol the orders belong to.
Code
Note: The payload above does not show all fields that can appear. Please refer to Conditional fields in Order Responses.
Account order history (USER_DATA)
Code
Query information about all your orders – active, canceled, filled – filtered by time range.
Weight: 20
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
orderId | LONG | NO | Order ID to begin at |
startTime | LONG | NO | |
endTime | LONG | NO | |
limit | INT | NO | Default: 500; Maximum: 1000 |
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 |
Notes:
-
If
startTimeand/orendTimeare specified,orderIdis ignored.Orders are filtered by
timeof the last execution status update. -
If
orderIdis specified, return orders with order ID >=orderId. -
If no condition is specified, the most recent orders are returned.
-
For some historical orders the
cummulativeQuoteQtyresponse field may be negative, meaning the data is not available at this time. -
The time between
startTimeandendTimecan't be longer than 24 hours.
Data Source: Database
Response:
Status reports for orders are identical to order.status.
Note that some fields are optional and included only for orders that set them.
Code
Query Order list (USER_DATA)
Code
Check execution status of an Order list.
For execution status of individual orders, use order.status.
Weight: 4
Parameters:
Notes:
-
origClientOrderIdrefers tolistClientOrderIdof the order list itself. -
If both
origClientOrderIdandorderListIdparameters are specified, onlyorigClientOrderIdis used andorderListIdis ignored.
Data Source: Database
Response:
Code
Current open order lists (USER_DATA)
Code
Query execution status of all open order lists.
If you need to continuously monitor order status updates, please consider using WebSocket Streams:
userDataStream.subscribeif on an authenticated sessionuserDataStream.subscribe.signatureif subscribing through signature subscription
Weight: 6
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: Database
Response:
Code
Account order list history (USER_DATA)
Code
Query information about all your order lists, filtered by time range.
Weight: 20
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
fromId | INT | NO | Order list ID to begin at |
startTime | LONG | NO | |
endTime | LONG | NO | |
limit | INT | NO | Default: 500; Maximum: 1000 |
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 |
Notes:
-
If
startTimeand/orendTimeare specified,fromIdis ignored.Order lists are filtered by
transactionTimeof the last order list execution status update. -
If
fromIdis specified, return order lists with order list ID >=fromId. -
If no condition is specified, the most recent order lists are returned.
-
The time between
startTimeandendTimecan't be longer than 24 hours.
Data Source: Database
Response:
Status reports for order lists are identical to orderList.status.
Code
Account trade history (USER_DATA)
Code
Query information about all your trades, filtered by time range.
Weight:
| Condition | Weight |
|---|---|
| Without orderId | 20 |
| With orderId | 5 |
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES | |
orderId | LONG | NO | |
startTime | LONG | NO | |
endTime | LONG | NO | |
fromId | INT | NO | First trade ID to query |
limit | INT | NO | Default: 500; Maximum: 1000 |
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 |
Notes:
-
If
fromIdis specified, return trades with trade ID >=fromId. -
If
startTimeand/orendTimeare specified, trades are filtered by execution time (time).fromIdcannot be used together withstartTimeandendTime. -
If
orderIdis specified, only trades related to that order are returned.startTimeandendTimecannot be used together withorderId. -
If no condition is specified, the most recent trades are returned.
-
The time between
startTimeandendTimecan't be longer than 24 hours.
Data Source: Memory => Database
Response:
Code
Unfilled Order Count (USER_DATA)
Code
Query your current unfilled order count for all intervals.
Weight: 40
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:
Code
Account prevented matches (USER_DATA)
Code
Displays the list of orders that were expired due to STP.
These are the combinations supported:
symbol+preventedMatchIdsymbol+orderIdsymbol+orderId+fromPreventedMatchId(limitwill 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:
Code
Account allocations (USER_DATA)
Code
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:
Code
Account Commission Rates (USER_DATA)
Code
Get current account commission rates.
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
symbol | STRING | YES |
Weight: 20
Data Source: Database
Response:
Code
Query Order Amendments (USER_DATA)
Code
Queries all amendments of a single order.
Weight: 4
Parameters:
| Name | Type | Mandatory | Description |
|---|---|---|---|
| symbol | STRING | YES | |
| orderId | LONG | YES | |
| fromExecutionId | 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:
Code
Query Relevant Filters (USER_DATA)
Code
Retrieves the list of filters relevant to an account on a given symbol.
This is the only method that shows if an account has MAX_ASSET
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:
Code
User Data Stream requests
User Data Stream subscription
General information:
- 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. - 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. - You can have only one active subscription for a given account on a given connection.
- If you have an authenticated session, then you can subscribe to events for that authenticated
account using
- Subscriptions are identified by a
subscriptionIdwhich is returned when starting the subscription. ThatsubscriptionIdallows you to map the events you receive to a given subscription.- All active subscriptions for a session can be found using
session.subscriptions.
- All active subscriptions for a session can be found using
- 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.
- A single session supports up to 1,000 active subscriptions simultaneously.
- To verify the status of User Data Stream subscriptions, check the
userDataStreamfield insession.status: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)
Code
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. - To check the subscription status, use
session.status, see theuserDataStreamflag indicating you have have an active subscription. - User Data Stream events are available in both JSON and SBE
sessions.
- Please refer to User Data Streams for the event format details.
- For SBE, only SBE schema 2:1 or later is supported.
Weight: 2
Parameters: NONE
Response:
Code
Unsubscribe from User Data Stream
Code
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:
Code
Listing all subscriptions
Code
Note:
- Users are expected to track on their side which subscription corresponds to which account.
Weight: 2
Data Source: Memory
Response:
Code
Subscribe to User Data Stream through signature subscription (USER_STREAM)
Code
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:
Code