360X
API ReferenceRESTWebsocketsFIX
SupportStatusWebsite
API ReferenceRESTWebsocketsFIX
SupportStatusWebsite
  1. FIX
  • Introduction
  • Getting Started
  • Connectivity Setup
  • Authentication
  • Session Management
  • Instrument Discovery
  • Market Data
  • Order Management
  • Request for Quote (RFQ)
  • Message Reference
  • Error Handling
  • Code Examples
  • Troubleshooting
  • Support & Ressources
  • Appendix
  • Exchange FIX Dictionary Downloads
  1. FIX

Session Management

Connection Workflow#

Complete Connection Sequence#

Logout (35=5)#

Purpose:
The Logout message gracefully terminates a FIX session. It signals the intention to disconnect and allows both parties to properly close the session and update sequence numbers.
When to Use:
When client application is shutting down
At end of trading day (if configured for daily sessions)
When switching between different sessions
In response to an unrecoverable error
Business Context:
Graceful disconnection is essential for maintaining session integrity. Sending a Logout message before disconnecting ensures that both parties agree on the final sequence numbers and session state. This prevents sequence number gaps and simplifies reconnection.

Logout Tags#

Client → Server or Server → Client
TagNameRequiredDescription
58TextNLogout reason

Example Logout Message#

8=FIXT.1.1|9=XXX|35=5|
58=End of trading day|
10=XXX|

Heartbeat Management#

Heartbeat (35=0)#

Purpose:
Heartbeat messages maintain session liveness by proving that both parties are connected and responsive. They're sent automatically when no other messages have been exchanged within the heartbeat interval.
When to Use:
Automatically sent when no messages exchanged within HeartBtInt seconds
In response to a TestRequest message
Never manually sent (handled by FIX engine)
Business Context:
Heartbeats are critical for high-availability trading systems. They ensure that network issues are detected quickly (within seconds) rather than waiting for a message timeout. This allows applications to reconnect promptly and minimize trading downtime.
Automatic Behavior:
The QuickFIX engine automatically handles heartbeat generation and monitoring. No manual intervention is required unless implementing custom session logic.

Example Heartbeat#

8=FIXT.1.1|9=XXX|35=0|
10=XXX|

Test Request (35=1)#

Purpose:
The Test Request message forces an immediate response from the counterparty. It's used to verify connectivity when you suspect a connection issue or when testing the session without sending business messages.
When to Use:
To verify the counterparty is responsive
After detecting unusual heartbeat delays
During connection testing and diagnostics
Before critical operations (e.g., market open)
Business Context:
Test Requests provide a reliable way to check session health without impacting business operations. They're particularly useful during market opens or before sending large batches of orders.

Test Request Tags#

TagNameRequiredDescription
112TestReqIDYUnique identifier echoed in Heartbeat response

Example Test Request#

# Send TestRequest
8=FIXT.1.1|9=XXX|35=1|
112=TEST-123|
10=XXX|

# Response: Heartbeat with TestReqID
8=FIXT.1.1|9=XXX|35=0|
112=TEST-123|
10=XXX|

Resend Request (35=2)#

Purpose:
The Resend Request message requests retransmission of messages when a sequence gap is detected. This is the primary recovery mechanism for ensuring message reliability and maintaining sequence integrity.
When to Use:
When you receive a message with an unexpected sequence number
After reconnecting to recover missed messages
During initialization to request missing historical messages
When implementing gap recovery logic
Business Context:
Message sequence integrity is crucial for trading systems. Missing messages could mean missed execution reports, order confirmations, or market data updates. The Resend Request ensures that no critical information is lost, even during network disruptions.

Resend Request Tags#

TagNameRequiredDescription
7BeginSeqNoYFirst message sequence number to resend
16EndSeqNoYLast message sequence number (0=all subsequent)

Example Scenarios#

Scenario 1: Request specific range
# Detected gap: received seq 25, expected seq 20
# Request messages 20-24
8=FIXT.1.1|9=XXX|35=2|
7=20|16=24|
10=XXX|
Scenario 2: Request all messages from a point
# Request all messages from sequence 100 onwards
8=FIXT.1.1|9=XXX|35=2|
7=100|16=0|
10=XXX|

Sequence Number Management#

How Sequence Numbers Work#

FIX uses sequence numbers (Tag 34: MsgSeqNum) to ensure message delivery and detect gaps. Each message sent or received increments the sequence number by 1.
Sequence Number Rules:
Starts at 1 for each session (or continues from previous if ResetOnLogon=N)
Increments by 1 for each message sent
Separate sequence numbers for inbound and outbound messages
Must be unique and sequential within a session

ResetOnLogon Configuration#

ResetOnLogon=Y (Recommended for Testing)
Resets sequence numbers to 1 on each logon
Simpler to implement and debug
No need to persist sequence numbers
Use for sandbox and initial testing
ResetOnLogon=N (Recommended for Production)
Maintains sequence numbers across sessions
Enables gap detection and message recovery
Requires persisting sequence numbers to disk
Use for production environments

Handling Sequence Gaps#

If you receive a message with an unexpected MsgSeqNum:
1.
Detect Gap: Expected seq=20, received seq=25 (gap of 5 messages)
2.
Send ResendRequest: Request messages 20-24
3.
Process Resent Messages: Handle PossDupFlag (Tag 43=Y)
4.
Resume Normal Processing: Continue with sequence 25+
Modified at 2026-03-09 15:06:12
Previous
Authentication
Next
Instrument Discovery