FIX API
[!NOTE]
This API can only be used with the SPOT Exchange.
General API Information
- FIX connections require TLS encryption. Please either use native TCP+TLS connection or set up a local proxy such as stunnel to handle TLS encryption.
- 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.
- If your request contains a symbol name containing non-ASCII characters, then the response may contain non-ASCII characters encoded in UTF-8.
- To ensure uninterrupted connectivity, please make sure that your client sends SNI (Server Name
Indication) during the TLS handshake and performs certificate validation against the intended
hostname.
Clients that do not send SNI may receive an unexpected certificate, which can result in TLS handshake or hostname verification failures.
Example implementations
NodeJS
If you are using Node.js and connecting via raw TLS sockets (tls.connect()), you must explicitly
set the servername option. Please refer to the sample below:
const tls = require("tls");
const hostname = "fix-dc.binance.com"; //EXAMPLE
const options = {
host: hostname,
port: 9002,
servername: hostname, // enables SNI
};
Note that: NodeJS doesn't enable SNI by default for TLS (See
https://nodejs.org/api/tls.html#tlsconnectoptions-callback).
If you are using standard HTTPS libraries in Node.js (e.g., https.request(), axios,
fetch), these typically set SNI automatically when connecting via a hostname/URL.
Other languages/custom TLS implementations
When using custom TLS agents / TLS APIs, ensure you set the equivalent field (often named
server_hostname, hostname, or ServerName) to the endpoint hostname so SNI is sent.
FIX sessions only support Ed25519 keys.
You can setup and configure your API key
permissions on Spot Test Network.
FIX API Order Entry sessions
- Endpoint is:
tcp+tls://fix-oe.testnet.binance.vision:9000 - Supports placing orders, canceling orders, and querying current limit usage.
- Supports receiving all of the account's ExecutionReport
<8>and List Status<N>. - Only API keys with
FIX_APIare allowed to connect. - QuickFIX Schema can be found here.
FIX API Drop Copy sessions
- Endpoint is:
tcp+tls://fix-dc.testnet.binance.vision:9000 - Supports receiving all of the account's ExecutionReport
<8>and List Status<N>. - Only API keys with
FIX_APIorFIX_API_READ_ONLYare allowed to connect. - QuickFIX Schema can be found here.
- Data in Drop Copy sessions is delayed by 1 second.
FIX API Market Data sessions
- Endpoint is:
tcp+tls://fix-md.testnet.binance.vision:9000 - Supports market data streams and active instruments queries.
- Does not support placing or canceling orders.
- Only API keys with
FIX_APIorFIX_API_READ_ONLYare allowed to connect. - QuickFIX Schema can be found here.
FIX Connection Lifecycle
- All FIX API sessions will remain open for as long as possible, on a best-effort basis.
- There is no minimum connection time guarantee; a server can enter maintenance at any time.
- When a server enters maintenance, a News
<B>message will be sent to clients every 10 seconds until disconnection, prompting clients to reconnect. Upon receiving this message, a client is expected to establish a new session and close the old one. If the client does not close the old session before the server disconnects it, the server will proceed to log it out and close the session.
- When a server enters maintenance, a News
- After connecting, the client must send a Logon
<A>request. For more information please refer to How to sign a Logon request. - The client should send a Logout
<5>message to close the session before disconnecting. Failure to send the logout message will result in the session’sSenderCompID (49)being unusable for new session establishment for a duration of 2x theHeartInt (108)interval. - The system allows negotiation of the
HeartInt (108)value during the logon process. Accepted values range between 5 and 60 seconds.- If the server has not sent any messages within a
HeartInt (108)interval, a HeartBeat<0>will be sent. - If the server has not received any messages within a
HeartInt (108)interval, a TestRequest<1>will be sent. If the server does not receive a HeartBeat<0>containing the expectedTestReqID (112)from the client withinHeartInt (108)seconds, the server will send a Logout<5>message and close the connection. - If the client has not received any messages within a
HeartInt (108)interval, the client is responsible for sending a TestRequest<1>to ensure the connection is healthy. Upon receiving such a TestRequest<1>, the server will respond with a Heartbeat<0>containing the expectedTestReqID (112). If the client does not receive the server’s response within aHeartInt (108)interval, the client should close the session and connection and establish new ones.
- If the server has not sent any messages within a
API Key Permissions
To access the FIX API order entry sessions, your API key must be configured with the FIX_API
permission.
To access the FIX Drop Copy sessions, your API key must be configured with either
FIX_API_READ_ONLY or FIX_API permission.
To access the FIX Market Data sessions, your API key must be configured with either FIX_API or
FIX_API_READ_ONLY permission.
FIX sessions only support Ed25519 keys.
On message processing order
The MessageHandling (25035) field required in the initial Logon<A> message
controls whether messages from the client may be reordered before they are processed by the Matching
Engine.
| Mode | Description |
|---|---|
UNORDERED(1) | Messages from the client are allowed to be sent to the matching engine in any order. |
SEQUENTIAL(2) | Messages from the client are always sent to the matching engine in MsgSeqNum (34) order. |
In all modes, the client's MsgSeqNum (34) must increase monotonically, with each subsequent
message having a sequence number that is exactly 1 greater than the previous message.
[!TIP]
UNORDERED(1)should offer better performance when there are multiple messages in flight from the client to the server.
Response Mode
By default, all concurrent order entry sessions receive all of the account's successful
ExecutionReport<8> and ListStatus<N> messages, including
those in response to orders placed from other FIX sessions and via non-FIX APIs.
Use the ResponseMode (25036) field in the initial Logon<A> message to change
this behavior.
EVERYTHING(1): The default mode.ONLY_ACKS(2): Receive only ACK messages whether operation succeeded or failed. Disables ExecutionReport push.
Timing Security
- All requests require a
SendingTime(52)field which should be the current timestamp. - An additional optional field,
RecvWindow(25000), specifies for how long the request stays valid in milliseconds.RecvWindow(25000)supports up to three decimal places of precision (e.g., 6000.346) so that microseconds may be specified.- If
RecvWindow(25000)is not specified, it defaults to 5000 milliseconds only for the Logon<A>request. For other requests if unset, the RecvWindow check is not executed. - Maximum
RecvWindow(25000)is 60000 milliseconds.
- Request processing logic is as follows:
serverTime = getCurrentTime()
if (SendingTime < (serverTime + 1 second) && (serverTime - SendingTime) <= RecvWindow) {
// begin processing request
serverTime = getCurrentTime()
if (serverTime - SendingTime) <= RecvWindow {
// forward request to Matching Engine
} else {
// reject request
}
// finish processing request
} else {
// reject request
}