## General information [#general-information] The B2CONNECT FIX server provides all the functionality necessary for real-time trading and receiving up-to-date market information via the Financial Information eXchange protocol. In this document, you can find a detailed description of the B2CONNECT FIX API, including the information about how to connect to a demo FIX server. The B2CONNECT FIX API is based on the version 4.4 of the Financial Information eXchange protocol. It’s assumed that the reader of this document is already familiar with the FIX protocol. To learn more about the protocol specification, see the [FIX Trading Community website](https://www.fixtrading.org/). If your trading engine is powered by Go, take a minute to learn about [SimpleFix Go](https://github.com/b2broker/simplefix-go/). This open-source library is provided by the B2CONNECT team to help you quickly integrate FIX messaging into your environment. The library is entirely written in Go and supports any FIX API version. ### Supported message types [#supported-message-types] The following message types can be assigned to the `<35> MsgType` field of a [Standard header](/b2connect/fix-api#standard-header): * `0` — [Heartbeat](/b2connect/fix-api#heartbeat) (Client ↔ B2CONNECT) * `1` — [Test Request](/b2connect/fix-api#test-request) (Client ↔ B2CONNECT) * `2` — [Resend Request](/b2connect/fix-api#resend-request) (Client ↔ B2CONNECT) * `3` — [Reject](/b2connect/fix-api#reject) (Client ← B2CONNECT) * `4` — [Sequence Reset](/b2connect/fix-api#sequence-reset) (Client ↔ B2CONNECT) * `5` — [Logout](/b2connect/fix-api#logout) (Client ↔ B2CONNECT) * `8` — [Execution Report](/b2connect/fix-api#execution-report) (Client ← B2CONNECT) * `9` — [Order Cancel Reject](/b2connect/fix-api#order-cancel-reject) (Client ← B2CONNECT) * `A` — [Logon](/b2connect/fix-api#logon) (Client → B2CONNECT) * `D` — [New Order Single](/b2connect/fix-api#new-order-single) (Client → B2CONNECT) * `F` — [Order Cancel Request](/b2connect/fix-api#order-cancel-request) (Client → B2CONNECT) * `V` — [Market Data Request](/b2connect/fix-api#market-data-request) (Client → B2CONNECT) * `W` — [Market Data — Snapshot/Full Refresh](/b2connect/fix-api#market-data-snapshot-full-refresh) (Client ← B2CONNECT) * `Y` — [Market Data Request Reject](/b2connect/fix-api#market-data-request-reject) (Client ← B2CONNECT) ### Standard header [#standard-header] All FIX messages must start with a **Standard header**. The **Standard header** includes the following fields: ### Standard trailer [#standard-trailer] Along with a Standard header, all FIX messages must also contain a **Standard trailer**. The **Standard trailer** includes the following fields: ## Session messages [#session-messages] The messages listed in this section are used to maintain any live FIX session with the B2CONNECT FIX server, including both [quoting](/b2connect/fix-api#quoting) and [trading](/b2connect/fix-api#trading) sessions. ### Heartbeat [#heartbeat] This message is sent back and forth between the FIX server and the client to check the connection status and in response to [Test Request](/b2connect/fix-api#test-request) messages. The **Heartbeat** message includes the following fields: ### Test Request [#test-request] This message is sent back and forth between the FIX server and the client in response to [Heartbeat](/b2connect/fix-api#heartbeat) messages as a means of connectivity check. The **Test Request** message includes the following fields: ### Resend Request [#resend-request] This message is sent by the client or FIX server to initiate the retransmission of messages, which may be required upon detecting a gap in the sequence numbers or losing a particular message. The **Resend Request** message includes the following fields: ### Reject [#reject] This message is sent by the FIX server upon receiving a malformed message from the client. The possible reason for rejection is specified in the `<373> SessionRejectReason` field. This message is unrelated to a trade-level rejection ([Order Cancel Reject](/b2connect/fix-api#order-cancel-reject)) issued when a FIX server is unable to place a requested order. The **Reject** message includes the following fields: #### Possible reasons [#possible-reasons] When the FIX server sends a [Reject](/b2connect/fix-api#reject) notification informing the client that a session-level request has been rejected, the `<373> SessionRejectReason` field can be set to one of the following values specifying the reason for message rejection: * `0` — an invalid tag number * `1` — a required tag is missing * `2` — a tag isn’t defined for this message type * `3` — a tag is undefined * `4` — a tag has no value assigned * `5` — an assigned value is incorrect (out of range) for this tag * `6` — an incorrect value data format * `7` — an issue related to decryption * `9` — an issue related to `CompID` * `10` — an accuracy issue related to `<52> SendingTime` * `11` — an invalid `<35> MsgType` * `12` — an XML validation error * `13` — the same tag appears more than once * `14` — a tag is specified not in the required order * `15` — a wrong order of repeating group fields * `17` — a non-“Data” value includes a field delimiter (an SOH character) * `99` — other (unspecified) reason ### Sequence Reset [#sequence-reset] This message is sent by the client or FIX server to indicate to the recipient the sequence number of the next message from the sender, immediately following the Sequence Reset message. This may be necessary to recover from a disconnect, in case if some messages were lost or their resending is not desirable. The **Sequence Reset** message includes the following fields: ### Logon [#logon] This message is sent by the client to initiate a FIX session. The **Logon** message includes the following fields: ### Logout [#logout] This message is sent by the client or FIX server to terminate a session. When terminated, the possible reason is specified in the `<58> Text` field. The **Logout** message includes the following fields: ## Demo mode [#demo-mode] The B2CONNECT FIX server supports a Demo mode that allows clients to establish a test connection and simulate quoting and trading sessions. Contact your account manager to obtain a set of settings and credentials. ## Quoting [#quoting] After connecting to the FIX server and establishing a live quoting session, the client can send a [Market Data Request](/b2connect/fix-api#market-data-request) to subscribe to quote updates streamed by B2CONNECT. To subscribe to multiple symbols, the client should send a separate [Market Data Request](/b2connect/fix-api#market-data-request) for each symbol. Upon successful subscription to a selected symbol, the FIX server starts streaming market data updates by sending [Market Data — Snapshot/Full Refresh](/b2connect/fix-api#market-data-snapshot-full-refresh) messages each time the market data is updated. The quote updates are streamed continuously for the entire duration of a FIX session. If a subscription request can’t be executed for some reason (for example, when a requested symbol isn’t found), the FIX server responds with a [Market Data Request Reject](/b2connect/fix-api#market-data-request-reject) message providing detailed information about an error. To terminate a specific subscription and stop receiving the updates, the client can send a [Market Data Request](/b2connect/fix-api#market-data-request) with the `<263> SubscriptionRequestType` set to `2` (standing for “Unsubscribe”). Upon sending a [Logout](/b2connect/fix-api#logout) request, the current session is closed and subscriptions to all ticker symbols are terminated. ### Market Data Request [#market-data-request] This message is sent by the client to start receiving up-to-date quoting data for a specified ticker symbol. The **Market Data Request** message includes the following fields: ### Market Data Request Reject [#market-data-request-reject] This message is sent by the FIX server to reject a [Market Data Request](/b2connect/fix-api#market-data-request) with invalid values. The **Market Data Request Reject** message includes the following fields: #### Possible reasons [#possible-reasons-1] The `<281> MDReqRejReason` field can be set to one of the following values specifying the reason for request rejection: * `0` — the specified symbol isn’t recognized * `1` — a duplicate `<262> MDReqID` * `2` — insufficient bandwidth * `3` — insufficient permissions * `4` — the specified `<263> SubscriptionRequestType` isn’t supported * `5` — the specified `<264> MarketDepth` isn’t supported * `6` — the specified `<265> MDUpdateType` isn’t supported * `8` — the specified `<269> MDEntryType` isn’t supported ### Market Data — Snapshot/Full Refresh [#market-data--snapshotfull-refresh] Such messages are continuously sent by the FIX server after the client subscribes to a ticker symbol. A new message is sent with each market data update. The **Market Data — Snapshot/Full Refresh** message includes the following fields: ## Trading [#trading] **Place an order** After establishing a trading session with the FIX server, the client can place a new order by sending a [New Order Single](/b2connect/fix-api#new-order-single) message. In response to this, the FIX server sends back an [Execution Report](https://docs.b2connect.b2broker.com/en/fix-api.html#execution-report) with the `<150> ExecType` field set to `A`, indicating that the order is placed successfully. If the order can’t be placed (for example, due to lack of credit funds or other issues), the report is sent with `<150> ExecType` set to `8`. After placing the order, the FIX server sends a separate report with `<150> ExecType` set to `F` each the order status changes: * If the order is executed partially, `<39> OrdStatus` is set to `1`. * When the order is fully filled, `<39> OrdStatus` is set to `2`. **Cancel an order** To cancel an open order, the client can send an [Order Cancel Request](/b2connect/fix-api#order-cancel-request). If the order is canceled (either explicitly by a trader, or automatically due to timeout), the [Execution Report](/b2connect/fix-api#execution-report) is sent with `<150> ExecType` set to `4`. In this case, the `<14> CumQty` field indicates the amount that has already been filled by the time the order was canceled, and `<151> LeavesQty` indicates the unfilled amount. If an order can’t be canceled for any reason, the FIX server sends back an [Order Cancel Reject](/b2connect/fix-api#order-cancel-reject) message indicating why the order cancellation failed. ### New Order Single [#new-order-single] This message is sent by the client to place a new order with specified parameters. The **New Order Single** message includes the following fields: ### Order Cancel Request [#order-cancel-request] This message is sent by the client to cancel an open order in its entire remaining amount. This request is assigned a unique `<11> ClOrdID` and is treated as a separate order. Upon successful cancellation of the order, an [Execution Report](/b2connect/fix-api#execution-report) is sent with the `<39> OrdStatus` field set to `4`. In this case, the `<14> CumQty` field indicates the amount that has already been filled by the time the order was canceled. If the order can’t be canceled for some reason, the FIX server sends back an [Order Cancel Reject](/b2connect/fix-api#order-cancel-reject) message indicating why the order cancellation failed. The **Order Cancel Request** message includes the following fields: ### Order Cancel Reject [#order-cancel-reject] This message is sent by the FIX server upon receiving an [Order Cancel Request](/b2connect/fix-api#order-cancel-request) that can’t be fulfilled. The **Order Cancel Reject** message includes the following fields: ### Execution Report [#execution-report] This message is sent by the FIX server upon successfully placing or cancelling an order, or any change to the order status (such as a complete or partial execution). Among other data, the report indicates: * the current order status at the moment of report creation (`<39> OrdStatus`) * the most recent change in the order status, which is being reported (`<150> ExecType`) The **Execution Report** message includes the following fields: