# FIX API

## 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.

{% hint style="info" %}
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/).
{% endhint %}

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

The following message types can be assigned to the `<35> MsgType` field of a [Standard header](#standard-header):

* `0` — [Heartbeat](#heartbeat) (Client ↔ B2CONNECT)
* `1` — [Test Request](#test-request) (Client ↔ B2CONNECT)
* `2` — [Resend Request](#resend-request) (Client ↔ B2CONNECT)
* `3` — [Reject](#reject) (Client ← B2CONNECT)
* `4` — [Sequence Reset](#sequence-reset) (Client ↔ B2CONNECT)
* `5` — [Logout](#logout) (Client ↔ B2CONNECT)
* `8` — [Execution Report](#execution-report) (Client ← B2CONNECT)
* `9` — [Order Cancel Reject](#order-cancel-reject) (Client ← B2CONNECT)
* `A` — [Logon](#logon) (Client → B2CONNECT)
* `D` — [New Order Single](#new-order-single) (Client → B2CONNECT)
* `F` — [Order Cancel Request](#order-cancel-request) (Client → B2CONNECT)
* `V` — [Market Data Request](#market-data-request) (Client → B2CONNECT)
* `W` — [Market Data — Snapshot/Full Refresh](#market-data-snapshot-full-refresh) (Client ← B2CONNECT)
* `Y` — [Market Data Request Reject](#market-data-request-reject) (Client ← B2CONNECT)

### Standard header

All FIX messages must start with a **Standard header**.

The **Standard header** includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td>8</td><td>BeginString</td><td>Y</td><td>String</td><td><p>Marks the beginning of a new message and indicates the FIX version (<code>FIX.4.4</code>).</p><p>Always the first field in a message.</p></td></tr><tr><td>9</td><td>BodyLength</td><td>Y</td><td>int</td><td><p>The message length, in bytes.</p><p>Always the second field in a message.</p></td></tr><tr><td>35</td><td>MsgType</td><td>Y</td><td>String</td><td><p>The message type. See <a href="#supported-message-types">Supported message types</a> for a list of supported values.</p><p>Always the third field in a message.</p></td></tr><tr><td>34</td><td>MsgSeqNum</td><td>Y</td><td>int</td><td><p>The message sequence number.</p><p>This value is incremented by 1 for each consecutive message.</p></td></tr><tr><td>49</td><td>SenderCompID</td><td>Y</td><td>String</td><td>The B2CONNECT-supplied identifier of a client sending requests to the FIX server.</td></tr><tr><td>52</td><td>SendingTime</td><td>Y</td><td>Timestamp</td><td>The date and time when a message was sent, in UTC time with milliseconds precision: <code>YYYYMMDD-HH:MM:SS.sss</code>.</td></tr><tr><td>56</td><td>TargetCompID</td><td>Y</td><td>String</td><td>The B2CONNECT-supplied identifier of a server receiving client messages.</td></tr></tbody></table>

### Standard trailer

Along with a Standard header, all FIX messages must also contain a **Standard trailer**.

The **Standard trailer** includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td>10</td><td>CheckSum</td><td>Y</td><td>int</td><td><p>A three-digit simple checksum indicating the end of a message.</p><p>Always the last field in a message.</p></td></tr></tbody></table>

## Session messages

The messages listed in this section are used to maintain any live FIX session with the B2CONNECT FIX server, including both [quoting](#quoting) and [trading](#trading) sessions.

### 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](#test-request) messages.

The **Heartbeat** message includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 0</code></td></tr><tr><td>112</td><td>TestReqID</td><td>N</td><td>String</td><td>The identifier of a <a href="#test-request">Test Request</a> in response to which this Heartbeat message is sent.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### Test Request

This message is sent back and forth between the FIX server and the client in response to [Heartbeat](#heartbeat) messages as a means of connectivity check.

The **Test Request** message includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 1</code></td></tr><tr><td>112</td><td>TestReqID</td><td>N</td><td>String</td><td>The identifier of this Test Request in response to which a <a href="#heartbeat">Heartbeat</a> message will be sent.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### 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:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 2</code></td></tr><tr><td>7</td><td>BeginSeqNo</td><td>Y</td><td>int</td><td>The number of the first message in a sequence to resend.</td></tr><tr><td>16</td><td>EndSeqNo</td><td>Y</td><td>int</td><td><p>The number of the last message in a sequence to resend:</p><ul><li>If <code>&#x3C;7> BeginSeqNo</code> = <code>&#x3C;16> EndSeqNo</code>, a single message in a sequence is resent.</li><li>If <code>&#x3C;16> EndSeqNo</code> = <code>0</code>, all messages in a sequence following the one defined in <code>&#x3C;7> BeginSeqNo</code> are resent.</li></ul></td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### 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.

{% hint style="info" %}
This message is unrelated to a trade-level rejection ([Order Cancel Reject](#order-cancel-reject)) issued when a FIX server is unable to place a requested order.
{% endhint %}

The **Reject** message includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 3</code></td></tr><tr><td>45</td><td>RefSeqNum</td><td>Y</td><td>int</td><td>The sequence number of a rejected message (<code>&#x3C;34> MsgSeqNum</code>).</td></tr><tr><td>371</td><td>RefTagID</td><td>N</td><td>int</td><td>The tag number of a field that caused message rejection.</td></tr><tr><td>372</td><td>RefMsgType</td><td>N</td><td>int</td><td>The type of a rejected message (<code>&#x3C;35> MsgType</code>).</td></tr><tr><td>373</td><td>SessionRejectReason</td><td>N</td><td>int</td><td><p>The reason why a message is rejected.</p><p>See <a href="#possible-reasons">Possible reasons</a> for a list of possible values.</p></td></tr><tr><td>58</td><td>Text</td><td>N</td><td>String</td><td>The detailed information about the rejection reason.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

#### Possible reasons

When the FIX server sends a [Reject](#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

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:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 4</code></td></tr><tr><td>123</td><td>GapFillFlag</td><td>N</td><td>Boolean</td><td><p>Indicates that this message replaces missing messages that won’t be resent:</p><ul><li><code>Y</code> — Gap fill, <code>&#x3C;34> MsgSeqNum</code> is valid and indicates the beginning of the gap fill range.</li><li><code>N</code> — Sequence reset, <code>&#x3C;34> MsgSeqNum</code> is ignored. As it may lead to losing messages, this mode should only be used in case of a disaster recovery situation.</li></ul></td></tr><tr><td>36</td><td>NewSeqNo</td><td>Y</td><td>int</td><td>The new sequence number.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### Logon

This message is sent by the client to initiate a FIX session.

The **Logon** message includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = A</code></td></tr><tr><td>98</td><td>EncryptMethod</td><td>Y</td><td>int</td><td><p>The message encryption method.</p><p>This value must always be <code>0</code>, indicating that no encryption method is used.</p></td></tr><tr><td>108</td><td>HeartBtInt</td><td>Y</td><td>int</td><td><p>The heartbeat interval, in seconds. Indicates how often the FIX server sends messages to the client as part of a connection health check.</p><p>The maximum value is <code>60</code>.</p></td></tr><tr><td>141</td><td>ResetSeqNumFlag</td><td>Y</td><td>Boolean</td><td><p>Indicates whether both parties of a FIX session should reset the currently used sequence numbers.</p><p>It’s recommended to set the flag to <code>Y</code> for <a href="#quoting">Quoting</a> sessions.</p></td></tr><tr><td>553</td><td>Username</td><td>N</td><td>String</td><td><p>The client username.</p><p>It should be specified if provided as part of the FIX credentials.</p></td></tr><tr><td>554</td><td>Password</td><td>Y</td><td>String</td><td>The client password, as provided by B2CONNECT.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### 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:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 5</code></td></tr><tr><td>58</td><td>Text</td><td>N</td><td>String</td><td>The detailed information about the reason for logging out.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

## 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

After connecting to the FIX server and establishing a live quoting session, the client can send a [Market Data Request](#market-data-request) to subscribe to quote updates streamed by B2CONNECT.

{% hint style="info" %}
To subscribe to multiple symbols, the client should send a separate [Market Data Request](#market-data-request) for each symbol.
{% endhint %}

Upon successful subscription to a selected symbol, the FIX server starts streaming market data updates by sending [Market Data — Snapshot/Full Refresh](#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](#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](#market-data-request) with the `<263> SubscriptionRequestType` set to `2` (standing for “Unsubscribe”). Upon sending a [Logout](#logout) request, the current session is closed and subscriptions to all ticker symbols are terminated.

### 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:

<table><thead><tr><th width="95">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = V</code></td></tr><tr><td>262</td><td>MDReqID</td><td>Y</td><td>String</td><td><p>The identifier of a Market Data Request.</p><p>This value must be unique for the duration of each session.</p><p>If <code>&#x3C;263> SubscriptionRequestType</code> is set to <code>2</code>, the <code>&#x3C;262> MDReqID</code> field indicates the ID of a previous Market Data Request to be discarded.</p></td></tr><tr><td>263</td><td>SubscriptionRequestType</td><td>Y</td><td>int</td><td><p>The type of response expected from the FIX server:</p><ul><li><code>1</code> — Subscribe (to receive updates as the market status changes).</li><li><code>2</code> — Unsubscribe (to stop streaming the market data for the specified ticker symbol).</li></ul></td></tr><tr><td>264</td><td>MarketDepth</td><td>Y</td><td>int</td><td><p>The market depth for an order book snapshot:</p><ul><li><code>0</code> — To obtain a full order book.</li><li><code>1</code> — To obtain top-of-the-book prices.</li><li>other value greater than zero — To obtain a specific number of price layers.</li></ul></td></tr><tr><td>265</td><td>MDUpdateType</td><td>Y</td><td>int</td><td>This value must always be <code>0</code>, indicating that all order book data should be updated every time in response to any change in the market data (as opposed to incremental updates related only to price levels that have changed at the<br>time).</td></tr><tr><td>267</td><td>NoMDEntryTypes</td><td>Y</td><td>int</td><td><p>The number of <code>&#x3C;269> MDEntryTypes</code> requested.</p><p>This value must always be <code>2</code>.</p></td></tr><tr><td>-> 269</td><td>MDEntryType</td><td>Y</td><td>int</td><td><p>The side of a quote:</p><ul><li><code>0</code> — Bid</li><li><code>1</code> — Ask</li></ul></td></tr><tr><td>146</td><td>NoRelatedSym</td><td>Y</td><td>int</td><td><p>The number of ticker symbols included in a subscription.</p><p>This value must always be <code>1</code>. To subscribe to multiple symbols, the client should send a separate Market Data Request for each symbol.</p></td></tr><tr><td>-> 55</td><td>Instrument</td><td>Y</td><td>String</td><td>The ticker symbol to subscribe to (such as <code>BTC/USDT</code>).</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### Market Data Request Reject

This message is sent by the FIX server to reject a [Market Data Request](#market-data-request) with invalid values.

The **Market Data Request Reject** message includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = Y</code></td></tr><tr><td>262</td><td>MDReqID</td><td>Y</td><td>String</td><td>The identifier of a rejected <a href="#market-data-request">Market Data Request</a>.</td></tr><tr><td>281</td><td>MDReqRejReason</td><td>N</td><td>int</td><td><p>The reason why a request is rejected.</p><p>See <a href="#possible-reasons-1">Possible reasons</a> for a list of supported values.</p></td></tr><tr><td>58</td><td>Text</td><td>N</td><td>String</td><td>The detailed information about the rejection reason.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

#### Possible reasons

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

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:

<table><thead><tr><th width="95">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = W</code></td></tr><tr><td>262</td><td>MDReqID</td><td>Y</td><td>String</td><td>The identifier of an originating <a href="#market-data-request">Market Data Request</a>.</td></tr><tr><td>55</td><td>Instrument</td><td>Y</td><td>String</td><td>The ticker symbol that’s being quoted (such as <code>BTC/USDT</code>).</td></tr><tr><td>268</td><td>NoMDEntries</td><td>Y</td><td>int</td><td>The number of market data entries (bids or asks) listed in a request.</td></tr><tr><td>-> 269</td><td>MDEntryType</td><td>Y</td><td>int</td><td><p>The side of a quote:</p><ul><li><code>0</code> — Bid</li><li><code>1</code> — Ask</li></ul></td></tr><tr><td>-> 270</td><td>MDEntryPx</td><td>Y</td><td>Price</td><td>The price for a market data entry.</td></tr><tr><td>-> 271</td><td>MDEntrySize</td><td>Y</td><td>Qty</td><td>The tradable volume of a market data entry.</td></tr><tr><td>-> 299</td><td>QuoteEntryID</td><td>N</td><td>String</td><td>The unique identifier of a quote.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

## 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](#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](#order-cancel-request).

If the order is canceled (either explicitly by a trader, or automatically due to timeout), the [Execution Report](#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](#order-cancel-reject) message indicating why the order cancellation failed.

### 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:

<table><thead><tr><th width="95">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = D</code></td></tr><tr><td>1</td><td>Account</td><td>N</td><td>String</td><td>The client-defined account name.</td></tr><tr><td>11</td><td>ClOrdID</td><td>Y</td><td>String</td><td><p>The client-provided identifier of an order.</p><p>This value must be unique across all previous trading sessions.</p></td></tr><tr><td>55</td><td>Instrument</td><td>Y</td><td>String</td><td>The ticker symbol that’s being (such as <code>BTC/USDT</code>).</td></tr><tr><td>54</td><td>Side</td><td>Y</td><td>int</td><td><p>The order side:</p><ul><li><code>1</code> — Buy</li><li><code>2</code> — Sell</li></ul></td></tr><tr><td>38</td><td>OrderQty</td><td>Y</td><td>Qty</td><td>The order amount.</td></tr><tr><td>40</td><td>OrdType</td><td>Y</td><td>Char</td><td><p>The order type:</p><ul><li><code>1</code> — Market</li><li><code>2</code> — Limit (when choosing this option, the <code>&#x3C;44> Price</code> field must be specified)</li></ul></td></tr><tr><td>44</td><td>Price</td><td>C</td><td>Price</td><td><p>The order price.</p><p>This field is required for Limit orders.</p></td></tr><tr><td>58</td><td>Text</td><td>N</td><td>String</td><td>Additional comments about the order.</td></tr><tr><td>59</td><td>TimeInForce</td><td>Y</td><td>Char</td><td><p>The time-in-force option applied to an order:</p><ul><li><code>1</code> — GTC (Good till Canceled)</li><li><code>3</code> — IOC (Immediate or Cancel)</li><li><code>4</code> — FOK (Fill or Kill)</li></ul></td></tr><tr><td>60</td><td>TransactTime</td><td>Y</td><td>Timestamp</td><td>The date and time when an order was created, in UTC time with milliseconds precision: <code>YYYYMMDD-HH:MM:SS.sss</code>.</td></tr><tr><td>21</td><td>HandlInst</td><td>Y</td><td>int</td><td>This field is ignored. Execution is always treated as if the supplied value was <code>1</code> (Automated execution order, private, no Broker intervention).</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### 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](#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](#order-cancel-reject) message indicating why the order cancellation failed.

The **Order Cancel Request** message includes the following fields:

<table><thead><tr><th width="84">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = F</code></td></tr><tr><td>41</td><td>OrigClOrdID</td><td>Y</td><td>String</td><td>The <code>&#x3C;11> ClOrdID</code> of an order to be canceled.</td></tr><tr><td>11</td><td>ClOrdID</td><td>Y</td><td>String</td><td>The client-provided unique identifier of the Order Cancel Request.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### Order Cancel Reject

This message is sent by the FIX server upon receiving an [Order Cancel Request](#order-cancel-request) that can’t be fulfilled.

The **Order Cancel Reject** message includes the following fields:

<table><thead><tr><th width="95">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 9</code></td></tr><tr><td>37</td><td>OrderID</td><td>Y</td><td>String</td><td><p>The unique identifier assigned to an order by the FIX server.</p><p>This value is <code>NONE</code> if <code>&#x3C;102> CxlRejReason = 1</code>.</p></td></tr><tr><td>41</td><td>OrigClOrdID</td><td>Y</td><td>String</td><td>The <code>&#x3C;11> ClOrdID</code> of an order to be canceled.</td></tr><tr><td>11</td><td>ClOrdID</td><td>Y</td><td>String</td><td>The client-provided unique identifier of the <a href="#order-cancel-request">Order Cancel Request</a>.</td></tr><tr><td>39</td><td>OrdStatus</td><td>Y</td><td>Char</td><td><p>The current order status by the moment of message generation:</p><ul><li><code>A</code> — The order is open and awaits execution.</li><li><code>1</code> — The order is open, some part of it may already be filled.</li><li><code>2</code> — The order is filled in the full amount.</li><li><code>4</code> — The order is canceled, some part of it may already be filled.</li><li><code>8</code> — The order is rejected, no part of it is filled.</li></ul></td></tr><tr><td>102</td><td>CxlRejReason</td><td>Y</td><td>int</td><td><p>The reason why a cancellation request is rejected:</p><ul><li><code>0</code> — Too late to cancel (the order has already been canceled or filled).</li><li><code>1</code> — Order unknown (the order with a specified ID wasn’t found by the FIX server).</li></ul></td></tr><tr><td>434</td><td>CxlRejResponseTo</td><td>Y</td><td>int</td><td><p>The type of a request that’s rejected.</p><p>This value must always be <code>1</code>, indicating the <a href="#order-cancel-request">Order Cancel Request</a>.</p></td></tr><tr><td>60</td><td>TransactTime</td><td>Y</td><td>Timestamp</td><td>The date and time of the last transaction made as part of order processing, in UTC time with milliseconds precision: <code>YYYYMMDD-HH:MM:SS.sss</code>.</td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>

### 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:

<table><thead><tr><th width="95">Tag</th><th width="167">Name</th><th width="80">Req'd</th><th width="123">Datatype</th><th>Description</th></tr></thead><tbody><tr><td></td><td><a href="#standard-header">Standard header</a></td><td>Y</td><td></td><td><code>&#x3C;35> MsgType = 8</code></td></tr><tr><td>11</td><td>ClOrdID</td><td>Y</td><td>String</td><td>The unique identifier assigned to an order by the client as part of a <a href="#new-order-single">New Order Single</a> request.</td></tr><tr><td>37</td><td>OrderID</td><td>Y</td><td>String</td><td>The unique identifier assigned to an order by the FIX server.</td></tr><tr><td>17</td><td>ExecID</td><td>Y</td><td>String</td><td><p>The unique identifier assigned by the FIX server to an individual execution.</p><p>This value is an empty string, if <code>&#x3C;150> ExecType</code> differs from <code>F</code> (Fill).</p></td></tr><tr><td>39</td><td>OrdStatus</td><td>Y</td><td>String</td><td><p>The current order status by the moment of message generation:</p><ul><li><code>A</code> — The order is open and awaits execution.</li><li><code>1</code> — The order is open, some part of it may already be filled.</li><li><code>2</code> — The order is filled in the full amount.</li><li><code>4</code> — The order is canceled, some part of it may already be filled.</li><li><code>8</code> — The order is rejected, no part of it is filled.</li></ul></td></tr><tr><td>150</td><td>ExecType</td><td>Y</td><td>String</td><td><p>The type of a received report:</p><ul><li><code>F</code> — The order is partially or fully filled (the report indicates the complete execution or specifies the part filled).</li><li><code>A</code> — The order is placed and awaits execution.</li><li><code>4</code> — The order is canceled, some part of it may already be filled.</li><li><code>8</code> — The order has been rejected, no part of it is filled.</li></ul></td></tr><tr><td>55</td><td>Instrument</td><td>Y</td><td>String</td><td>The ticker symbol of an instrument listed in the original order request (such as <code>BTC/USDT</code>).</td></tr><tr><td>54</td><td>Side</td><td>Y</td><td>int</td><td><p>The order side:</p><ul><li><code>1</code> — Buy</li><li><code>2</code> — Sell</li></ul></td></tr><tr><td>38</td><td>OrderQtyData</td><td>Y</td><td>Qty</td><td>The order amount, as indicated in the initial order.</td></tr><tr><td>40</td><td>OrdType</td><td>Y</td><td>int</td><td><p>The order type:</p><ul><li><code>1</code> — Market</li><li><code>2</code> — Limit</li></ul></td></tr><tr><td>44</td><td>Price</td><td>N</td><td>Price</td><td><p>The order bid or ask price.</p><p>This field is included in the Execution Report for limit orders only.</p></td></tr><tr><td>59</td><td>TimeInForce</td><td>Y</td><td>Char</td><td><p>The time-in-force option applied to an order:</p><ul><li><code>1</code> — GTC (Good till Canceled)</li><li><code>3</code> — IOC (Immediate or Cancel)</li><li><code>4</code> — FOK (Fill or Kill)</li></ul></td></tr><tr><td>31</td><td>LastPx</td><td>N</td><td>Price</td><td>For reports signaling a trade execution (<code>&#x3C;150> ExecType = F</code>), indicates the price of the last fill.</td></tr><tr><td>32</td><td>LastQty</td><td>N</td><td>Qty</td><td>For reports signaling a trade execution (<code>&#x3C;150> ExecType = F</code>), indicates the amount of the last fill.</td></tr><tr><td>151</td><td>LeavesQty</td><td>Y</td><td>Qty</td><td>For reports signaling a trade execution (<code>&#x3C;150> ExecType = F</code>), indicates the remaining order amount awaiting execution, taking into account the amount filled most recently.</td></tr><tr><td>14</td><td>CumQty</td><td>Y</td><td>Qty</td><td>The total order amount filled so far, including the amount filled most recently.</td></tr><tr><td>6</td><td>AvgPx</td><td>Y</td><td>Price</td><td><p>The average price calculated based on all order parts filled so far, taking into account the most recent execution.</p><p>This value is <code>0</code> for orders that are still awaiting execution (<code>&#x3C;150> ExecType = A</code>).</p></td></tr><tr><td>64</td><td>SettlDate</td><td>N</td><td>Date</td><td>For reports signaling a trade execution (<code>&#x3C;150> ExecType = F</code>), indicates the UTC date of a trade settlement, in the <code>YYYYMMDD</code> format.</td></tr><tr><td>75</td><td>TradeDate</td><td>N</td><td>Date</td><td>For reports signaling a trade execution (<code>&#x3C;150> ExecType = F</code>), indicates the UTC date of a fill, in the <code>YYYYMMDD</code> format.</td></tr><tr><td>103</td><td>OrdRejReason</td><td>N</td><td>int</td><td>For reports signaling an order rejection (<code>&#x3C;150> ExecType = F</code>), indicates the rejection reason.</td></tr><tr><td>58</td><td>Text</td><td>N</td><td>String</td><td>For canceled (<code>&#x3C;150> ExecType = 8</code>) or rejected (<code>&#x3C;150> ExecType = 4</code>) orders, provides the reason why an order is discarded.</td></tr><tr><td>60</td><td>TransactTime</td><td>C</td><td>Timestamp</td><td><p>The date and time of the most recent change in the order status, in UTC time with milliseconds precision: <code>YYYYMMDD-HH:MM:SS.sss</code>.</p><p>This field is omitted for orders that are still awaiting execution (<code>&#x3C;150> ExecType = A</code>).</p></td></tr><tr><td></td><td><a href="#standard-trailer">Standard trailer</a></td><td>Y</td><td></td><td></td></tr></tbody></table>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.b2connect.b2broker.com/fix-api/fix-api.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.