> For the complete documentation index, see [llms.txt](https://guide.traderevolution.com/traderevolution-api/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.traderevolution.com/traderevolution-api/traderevolution-apis/fix-api/session-level-messages.md).

# Session level messages

The following messages are session-level messages and are processed by our server using the QuickFIX engine. Some of these messages can be generated as well as accepted by our server, and some messages are expected to be received only.

### Heartbeat

Heartbeat messages can be initiated by either the client or the server.

| Tag | Field Name         | Required | Comments                                                                       |
| --- | ------------------ | -------- | ------------------------------------------------------------------------------ |
|     | *Standard Header*  | *Y*      | MsgTyp*e = 0*                                                                  |
| 112 | TestReqID          | Y        | Set by the server when responding to a Test Request message. Data type: string |
|     | *Standard Trailer* | *Y*      |                                                                                |

### Test request

Test Request messages may be initiated by the client or the server. The server may initiate this message under the control of the QuickFIX engine if it believes there is a problem with the socket.

Upon receipt of this message, the server will respond with a Heartbeat message.

| Tag | Field Name         | Required | Comments                                                    |
| --- | ------------------ | -------- | ----------------------------------------------------------- |
|     | *Standard Header*  | *Y*      | *MsgType = 1*                                               |
| 112 | TestReqID          | Y        | Will be returned in tag 112 of Heartbeat. Data type: string |
|     | *Standard Trailer* | *Y*      |                                                             |

### Resend request

Either the client or the server, in response to a detected gap in the message sequences, can initiate a Resend Request message. It requests a resend of the messages from BeginSeqNo through to and including EndSeqNo.

| Tag | Field Name         | Required | Comments      |
| --- | ------------------ | -------- | ------------- |
|     | *Standard Header*  | *Y*      | *MsgType = 2* |
| 7   | BeginSeqNo         | Y        |               |
| 16  | EndSeqNo           | Y        |               |
|     | *Standard Trailer* | *Y*      |               |

A Resend Request will be responded to by retransmitting the requested messages, or by transmitting a Sequence Reset (Gap Fill) to skip some of those messages.

### Reject (Session)

A message reject is issued when an incoming message fails session-level validation. Either the client or the server can produce this message, although the client is very unlikely to do so, as all fix messages produced by the server are supposed to be FIX-compliant.

When this type of message is produced by the server, the error will have been detected by the QuickFIX engine and suitable text will be found in tag 58. The field in error is found in tag 371 and the sequence number of the message in error is found in tag 45.

| Tag | Field Name          | Required | Comments                        |
| --- | ------------------- | -------- | ------------------------------- |
|     | *Standard Header*   | *Y*      | *MsgType = 3*                   |
| 45  | RefSeqNum           | Y        | MsgSeqNum of rejected message   |
| 371 | RefTagID            | Y        | The tag failing validation      |
| 372 | RefMsgType          | Y        | MsgType of the message in error |
| 373 | SessionRejectReason | Y        | Refer to FIX documentation      |
| 58  | Text                | Y        | Message to explain the error    |
|     | *Standard Trailer*  | *Y*      |                                 |

### Sequence reset

The client may generate a Sequence Reset message when responding to a Resend Request in order to skip messages. Please read the information on the importance of proper sequence number reset co-ordination and sequence number processing in section This is a recommended mechanism to ensure that stale orders are not re-transmitted in the event that the connection has been down for an extended period.

This message is not produced by the server, when the server responds to Resend Requests all requested messages are re-sent.

| Tag | Field Name         | Required | Comments                          |
| --- | ------------------ | -------- | --------------------------------- |
|     | *Standard Header*  | *Y*      | *MsgType = 4*                     |
| 123 | GapFillFlag        | N        | Normally present and set to “Y”   |
| 36  | NewSeqNo           | Y        | Must only increase expected SeqNo |
|     | *Standard Trailer* | *Y*      |                                   |

The GapResetFlag (tag 123) should normally be present and set to “Y” in order to skip the messages. This is called a Sequence Reset (Gap Fill) and the server will set the next expected sequence number to the value of NewSeqNo (tag 36), thus skipping intervening messages. It is important to note that the sequence number of this message should be the sequence number of the first message to be skipped.

### Logon 

FIX logon authentication requires a valid application user SenderID name and a password. The user must have rights for logon as “FIX client”.

Logon can be rejected for a number of reasons:

* the login name or password are invalid
* the user is already logged in the system in a different FIX session or via other means
* Logon request message sequence number is smaller than the last received FIX message (MsgSeqNum too low) – manual intervention on the client side is required to correct the sequence numbers and/or reset them via ResetSeqNumFlag field.
* You have connected to wrong Cluster Node – it’s required to recconect to another node (required IP adress and port you can find in Logout message).

A Logout message is sent in all these cases with the Text(58) field containing the error description.

<table><thead><tr><th width="196">Tag</th><th>Field Name</th><th>Required</th><th>Comments</th></tr></thead><tbody><tr><td></td><td><em>Standard Header</em></td><td>Y</td><td>MsgType = 5</td></tr><tr><td>58</td><td>Text</td><td>N</td><td></td></tr><tr><td>20005</td><td>NoClusterNodes</td><td>N</td><td>Total number of nodes in cluster</td></tr><tr><td>         20009</td><td>NodeID</td><td>Y</td><td>Id of the cluster node</td></tr><tr><td>         20008</td><td>ConnectionMode</td><td>Y</td><td>1 – Quote stream<br>2 – Trade stream<br>3 – Quote &#x26; Trade stream</td></tr><tr><td>         20007</td><td>NodeLoad</td><td>Y</td><td>Load of the cluster node</td></tr><tr><td>         20001</td><td>NoServerURLs</td><td>N</td><td>These data group provides information how you can connect to cluster node</td></tr><tr><td>                      20002</td><td>NodeHost</td><td>Y</td><td>IP or URL of the node</td></tr><tr><td>                      20003</td><td>NodePort</td><td>Y</td><td>port number</td></tr><tr><td>                      20004</td><td>NodeProtocol</td><td>Y</td><td>FIX API = 2</td></tr><tr><td></td><td><em>Standard Trailer</em></td><td>Y</td><td></td></tr></tbody></table>

### Logout

This message is created by the client application when it wishes to disconnect a session.

<table><thead><tr><th width="184">Tag</th><th width="264">Field Name</th><th width="120">Required</th><th>Comments</th></tr></thead><tbody><tr><td></td><td><em>Standard Header</em></td><td><em>Y</em></td><td><em>MsgType = 5</em></td></tr><tr><td>58</td><td>Text</td><td>N</td><td></td></tr><tr><td>20005</td><td>NoClusterNodes</td><td>N</td><td>Total number of nodes in cluster</td></tr><tr><td>          20009</td><td>NodeID</td><td>Y</td><td><p>Id of the cluster node. </p><p>1 – Quote stream<br>2 – Trade stream<br>3 – Quote &#x26; Trade stream</p></td></tr><tr><td>          20008</td><td>ConnectionMode</td><td>Y</td><td></td></tr><tr><td>          20007</td><td>NodeLoad</td><td>Y</td><td>Load of the cluster node</td></tr><tr><td>          20001</td><td>NoServerURLs</td><td>N</td><td>These data group provides information how you can connect to cluster node</td></tr><tr><td>                     20002</td><td>NodeHost</td><td>Y</td><td>IP or URL of the node</td></tr><tr><td>                     20003</td><td>NodePort</td><td>Y</td><td>port number</td></tr><tr><td>                     20004</td><td>NodeProtocol</td><td>Y</td><td>FIX API = 2</td></tr><tr><td></td><td><em>Standard Trailer</em></td><td>Y</td><td></td></tr></tbody></table>