FIX API Guide
Direct Market Access · Automated Trading · Getting Connected. This guide explains what FIX is, the three ElectronX FIX APIs, how a FIX session works, session identifiers and account mapping, the path to production, the documentation library, and frequently asked questions.
What is FIX?
FIX stands for Financial Information eXchange. It is an industry-standard communications protocol that financial systems use to talk to each other — for submitting orders, receiving executions, subscribing to market data, and managing trading sessions programmatically.
FIX was developed specifically for financial markets and is used by exchanges, clearing houses, brokers, and trading firms worldwide.
Why does ElectronX use FIX?
FIX gives your systems direct, low-latency access to ElectronX's order book and market data without any manual interaction with the GUI. It is the right tool when you need to:
- Submit orders programmatically from an algorithm or automated system
- Subscribe to real-time market data feeds for price signals or risk monitoring
- Maintain a real-time record of all firm trading activity for reconciliation or compliance
- Execute at speed or volume that manual GUI trading cannot support
FIX vs. the GUI — which do you need to trade?
The ElectronX trading interface (GUI) at trade.electronx.com is the right tool for manual trading — placing individual orders, monitoring positions, and reviewing settlement. The FIX API is the right tool for firms that want their systems to trade on their behalf or have a greater need for speed.
Both access the same exchange. Many firms use both: the GUI for monitoring and manual intervention, FIX for automated execution.
ElectronX FIX gateways use FIXT.1.1 for the session (transport) layer and FIX v5.0 SP2 for the application layer. Your FIX engine must be FIX 5.0 SP2 compliant. ElectronX is compatible with any standards-compliant FIX 5.0 SP2 implementation — the choice of FIX engine is yours.
The three FIX APIs
ElectronX offers three distinct FIX APIs. You can request access to each individually, and most automated trading setups will use all three.
| API | Purpose | What you send / receive |
|---|---|---|
| Order Entry | Submit, modify, and cancel orders | You send: NewOrderSingle, OrderCancelRequest, OrderCancelReplaceRequest. You receive: ExecutionReports (confirmations, fills, rejections, cancellations). |
| Market Data | Receive real-time prices and order book depth | You send: MarketDataRequest (subscribe), SecurityListRequest (instrument list). You receive: MarketDataSnapshotFullRefresh, MarketDataIncrementalRefresh. |
| Drop Copy | Receive a real-time copy of all firm execution activity (read-only) | Receive only: ExecutionReports for all trades across your firm, regardless of which user or session placed them. Used by risk, compliance, and operations teams. |
Order Entry
The Order Entry API is how your systems place, modify, and cancel orders on ElectronX. Each Order Entry session is associated with a specific Trading Desk and Clearing Member. You can only submit API orders using Trading Accounts that belong to the configured Trading Desk.
Each session has a unique SenderCompID following the format D-{TRADING_DESK_ID}-OE{nn} — for example, D-POLARIS-01-OE01. You can have multiple Order Entry sessions per Trading Desk, which is useful for distributing traffic across TCP connections or isolating different algorithms.
Key requirement: all order-related messages must include a SenderSubID (FIX Tag 50) identifying the specific trader or system placing the order. This is required for audit trail purposes.
Market Data
The Market Data API provides a real-time stream of prices and order book depth for any contracts you subscribe to. Market Data sessions are associated with your customer label rather than a specific Trading Desk, allowing a single session to serve your entire firm's data needs.
After connecting, you first send a SecurityListRequest to retrieve the current list of available contract symbols. You then send a MarketDataRequest for each instrument you want to watch. ElectronX responds with a full snapshot of the current order book, followed by incremental updates as the book changes.
Market Data is read-only. You cannot submit orders through a Market Data session.
Drop Copy
The Drop Copy API provides a real-time copy of all execution activity within the scope of your Clearing Member — regardless of which Order Entry session or individual trader generated it. If your firm has five traders on five separate Order Entry sessions, your Drop Copy session sees all five streams consolidated in one place.
Drop Copy is receive-only. It is primarily used by risk managers, operations teams, and compliance functions that need visibility across all firm trading activity without being on the Order Entry session themselves.
Use the Order Entry data dictionaries (FIX50SP2_OE.xml and FIXT11_OE.xml) for Drop Copy sessions as well as Order Entry sessions.
How a FIX session works
A FIX session is a persistent, authenticated TCP connection between your system and an ElectronX gateway. It has a defined lifecycle that both sides follow.
Session lifecycle
- Your system initiates a Logon message. This includes your
SenderCompID, the target (EXI), your heartbeat interval, and the FIX version being used. Do not includeSenderSubIDin the Logon message — this will cause the logon to be rejected. - ElectronX responds with a Logon confirmation.
- Both sides begin exchanging messages. Your system sends orders; ElectronX sends execution reports. Heartbeats are exchanged every 30 seconds to confirm the connection is alive.
- If the connection drops unexpectedly, your system should reconnect and use
ResendRequestto replay any messages that may have been missed. Sequence numbers allow both sides to identify gaps. - To close the session intentionally, send a Logout message. ElectronX will respond and the connection terminates cleanly.
copy8=FIX.4.2|9=72|35=A|49=CLIENT|56=ELECTRONX|34=1|52=20260529-14:30:00|98=0|108=30|10=171|
Sequence numbers
Every FIX message carries a sequence number (MsgSeqNum, Tag 34). Sequence numbers are strictly sequential and must not have gaps. If ElectronX detects a gap in your sequence numbers, it will request a replay of the missing messages via ResendRequest.
Sequence numbers reset to 1 every Sunday at 06:15 UTC. Your FIX configuration must account for this weekly reset. After the reset, both sides send a Logon message with ResetSeqNumFlag=Y (Tag 141=Y) to confirm the reset.
Heartbeats
If no messages are exchanged for 30 seconds, FIX requires a Heartbeat message — essentially a ping to confirm the session is still live. Your FIX library handles this automatically. If heartbeats stop, ElectronX assumes the connection has been lost and will close the session.
Cancel on Disconnect and Cancel on Logout
Cancel on Disconnect (CoD) is enabled by default on all Order Entry sessions. If your session drops unexpectedly (network interruption, engine crash, or missed heartbeats), all resting DAY orders submitted through that session are automatically canceled. GTC orders are unaffected and remain on the book.
Cancel on Logout (CoL) applies when you send a clean Logout (35=5) and carries the same behavior as CoD: DAY orders are canceled, and GTC orders persist. All of the cancellation logic from CoD applies here as well, with the addition that a graceful logout also triggers it.
SSL/TLS encryption
All FIX sessions are encrypted using SSL/TLS. ElectronX provides three files when it provisions your gateways: your private key (tls.key), your certificate (cert.crt), and ElectronX's Certificate Authority certificate (ca.pem). Your FIX configuration must reference all three. Keep your private key secure — never share it or commit it to source control.
Session identifiers and account mapping
Each FIX session is identified by a SenderCompID, which ElectronX uses to route messages and enforce access controls. The SenderCompID naming convention reflects the session type and the account it is associated with.
| Session type | SenderCompID format | Example |
|---|---|---|
| Order Entry | D-{TRADING_DESK_ID}-OE{nn} | D-POLARIS-01-OE01 |
| Market Data | {CUSTOMER_LABEL}-MD{nn} | POLARIS-MD01 |
| Drop Copy | CM-{CLEARING_MEMBER_ID}-DC{nn} | CM-POLARIS-DC01 |
Order Entry sessions can only access Trading Accounts that match both the Trading Desk and the Clearing Member configured for that session. If your firm has multiple Trading Desks, each desk needs its own Order Entry session. This allows you to enforce risk controls at the session level.
Discovering available contracts
Contract symbols must be retrieved programmatically through the FIX API using the SecurityListRequest message (35=x) on a Market Data session. ElectronX lists contracts on a rolling 5-day basis and new contracts are added hourly as old ones expire, so the list changes continuously.
The SecurityList response (35=y) contains all currently active symbols. Your system should retrieve this list at connection and refresh it periodically. You cannot subscribe to market data or place orders without a valid, current symbol — symbols include the exact delivery date and hour, and even a one-character difference will cause rejection.
Bounded Futures: BFUT{cap}-{ISO}-{HUB}-{YYMMDD}-{HH}
Binary Options: BOPT-{ISO}-{HUB}-{YYMMDD}-{HH}
Examples: BFUT500-ERCOT-HB_NORTH-250402-09, BOPT-ERCOT-HB_NORTH-250402-09
Placing an order
Order Entry messages such as NewOrderSingle (35=D) carry the symbol, side, quantity, order type, price, and time-in-force. A sample order message:
copy35=D|11=ORD1001|55=BFUT100|54=1|38=10|40=2|44=42.50|59=0|
The path to production
Access to ElectronX's FIX production environment requires demonstrating technical readiness in the Beta environment first. The process follows five stages.
Stage 1: request provisioning
Indicate your FIX API requirements during Phase 2 of the onboarding process. Specify which APIs you need (Order Entry, Market Data, Drop Copy) and how many sessions of each. If you are unsure, a single session of each type is a reasonable default — additional sessions can be added later.
ElectronX will provision your Beta gateways, generate your SSL certificates, and prepare a FIX Connectivity Details document specific to your firm.
Stage 2: receive your materials
ElectronX will provide the following materials when your gateways are provisioned. Files are delivered via SFTP (recommended for automated retrieval) or a secure shared folder.
- FIX Connectivity Details document: Contains your
SenderCompIDs, gateway hostnames and ports,SenderSubIDformat for Order Entry, and connection instructions. - SSL certificates: Three files —
tls.key(your private key),cert.crt(your certificate), andca.pem(ElectronX's CA certificate). - Technical documentation: FIX Specification, FIX Reference Guide, QuickFix Setup Guide, Basic FIX Connectivity Guide, and XML data dictionaries.
Beta and Production are completely separate systems with different credentials, different certificates, and different gateway addresses. You will not receive Production credentials until after successful Beta testing. Never use Beta credentials against Production or vice versa.
Stage 3: configure your FIX client
Choose and install your FIX engine. ElectronX's gateways are compatible with any FIX 5.0 SP2 compliant implementation. Configure your client using the SenderCompIDs, gateway addresses, and SSL certificates from your FIX Connectivity Details document. You may use the ElectronX data dictionaries (provided in your materials package) rather than standard FIX dictionaries — they include ElectronX-specific fields and validated enum values that standard dictionaries lack.
Stage 4: test and validate in Beta
Beta uses test collateral and has no real trading consequences. Work through the following validation sequence before requesting Production access:
- Logon and Logout successfully.
- Send and cancel orders. Confirm ExecutionReports are received correctly.
- Execute trades against the order book. Verify fill notifications.
- Subscribe to market data and confirm snapshot and incremental updates.
- Test reconnection — disconnect intentionally and verify session resumes correctly with
ResendRequestreplay. - Simulate the Sunday sequence number reset.
- Reach the minimum message counts required for Production approval (see below).
Minimum message counts for Production approval
Before ElectronX will provision Production access, your client system must demonstrate the following minimum activity in Beta. These counts apply to the session layer (all APIs) and then to the relevant application layer for each API you are requesting.
| Message type | FIX tag | Minimum count |
|---|---|---|
| Session Layer — All APIs | ||
| Logon | 35=A | 5 |
| Logout | 35=5 | 5 |
| Heartbeat | 35=0 | 30 |
| ResendRequest | 35=2 | 5 |
| Order Entry Application Layer | ||
| NewOrderSingle | 35=D | 50 |
| OrderCancelRequest | 35=F | 25 |
| OrderCancelReplaceRequest | 35=G | 10 |
| Market Data Application Layer | ||
| MarketDataRequest | 35=V | 5 |
| MarketDataSnapshotFullRefresh (received) | 35=W | 20 |
| MarketDataIncrementalRefresh (received) | 35=X | 50 |
| SecurityListRequest | 35=x | 1 |
Provisioning decisions are at ElectronX's sole discretion. Meeting minimum counts is necessary but not necessarily sufficient — ElectronX will also review logs for signs of repeated configuration errors, inability to handle rejections, or runaway/poorly controlled activity.
Stage 5: receive Production credentials and go live
Once Beta requirements are met, your account collateral is deposited and cleared, and ElectronX's internal review is complete, you will receive a new FIX Connectivity Details document and new SSL certificates for the Production environment.
Production credentials are completely separate from Beta. You must reconfigure your FIX client with the new SenderCompIDs, new gateway addresses, and new certificates before connecting to Production.
To request Production provisioning, email support@electronx.com once you have met all Beta testing requirements.
Documentation library
The following documents are provided by ElectronX to support your FIX integration.
The authoritative reference for all message formats, fields, and trading functionality available on ElectronX via FIX. Covers every message type for Order Entry and Market Data, required and optional fields with FIX tag numbers, data types and enum values, component definitions (standard header and trailer), session-level management (Logon, Logout, Heartbeat, ResendRequest), order lifecycle (NewOrderSingle, ExecutionReport states, cancel-replace), market data subscription and incremental update formats, and ElectronX-specific extensions. This is the document your development team will use most heavily during integration. Latest release: July 2026.
Covers system architecture, network connectivity, SenderCompID naming conventions, session configuration details, sample QuickFIX configuration files, and entity model examples. Includes three worked examples showing how account structure (Trading Desks, Clearing Members, Collateral Accounts) maps to FIX session configuration — useful for firms with multiple desks or complex organizational structures. Also contains the data dictionary filenames and how to reference them in your configuration. Complement to the FIX Specification; read this alongside the Specification rather than instead of it.
A plain-English introduction to FIX designed for people who need to understand what their technical teams are building, or for developers new to financial market protocols. Explains what FIX is and why exchanges use it, describes the three session types in practical terms, walks through a typical order lifecycle step by step, covers the five-stage journey from provisioning request to production go-live, and includes a troubleshooting section for common first-time setup problems (connection refused, logon rejected, sequence number issues, SSL certificate problems). Does not require a technical background to understand.
A practical configuration guide for teams using QuickFix libraries to implement their FIX engine. Covers library selection and version requirements, configuration file examples for Order Entry, Market Data, and Drop Copy sessions, critical configuration settings explained (sequence number management, ResetOnLogon behavior, SSL/STunnel connectivity), and common QuickFix mistakes and how to avoid them. Note: ElectronX does not endorse or require QuickFix — this guide exists because many customers choose it. ElectronX's gateways are compatible with any FIX 5.0 SP2 compliant implementation. ElectronX does not provide support for QuickFix library issues beyond what is documented in this guide.
Defines the requirements your client system must meet in the Beta environment before ElectronX will provision Production access. Specifies minimum message counts for each API and session layer, describes what ElectronX will review in your Beta logs (message patterns, error handling, configuration quality), and outlines the provisioning decision process. The framework sets the bar for Production readiness — review this before beginning Beta testing so you understand what you are working toward.
ElectronX provides four XML data dictionary files that define the exact message structures, field definitions, and enum values for each session type. These dictionaries are customized for ElectronX and include fields and enum values not present in standard FIX 5.0 SP2 dictionaries. Use the Order Entry dictionaries for both Order Entry and Drop Copy sessions; use the Market Data dictionaries only for Market Data sessions. FIX50SP2_OE.xml — Application-layer dictionary for Order Entry and Drop Copy; FIXT11_OE.xml — Transport-layer dictionary for Order Entry and Drop Copy; FIX50SP2_MD.xml — Application-layer dictionary for Market Data; FIXT11_MD.xml — Transport-layer dictionary for Market Data.
FAQ: FIX API
Do I need to use a specific FIX library?
No. ElectronX's gateways are compatible with any FIX 5.0 SP2 compliant implementation. You are responsible for selecting, installing, and maintaining your own FIX engine. ElectronX provides a QuickFix setup guide because many customers choose it, but this is not an endorsement or a requirement.
Can I test against Production before going live?
No. Beta and Production are completely separate systems. All testing must be completed in Beta before Production credentials are issued. You will never use Beta credentials against Production, and vice versa.
What happens to my orders if I disconnect?
All DAY orders are automatically cancelled if your Order Entry session disconnects or you send a Logout. GTC orders remain active on the order book. When you reconnect, use ResendRequest to replay any messages you may have missed during the disconnection window.
How often do sequence numbers reset?
Every Sunday at 06:15 UTC. Both sides reset sequence numbers to 1 and exchange Logon messages with ResetSeqNumFlag=Y. Messages from the prior week cannot be replayed after the reset. Your FIX configuration must account for this; the QuickFix Setup Guide covers ResetOnTime settings.
Why do I need to use ElectronX's data dictionaries instead of standard FIX ones?
You are not required to use ElectronX's data dictionaries. However, ElectronX's XML dictionaries include ElectronX-specific fields, correct enum values for rejection reasons, and support for PossDupFlag used in message replay. Using standard FIX dictionaries may cause validation errors and integration issues. We recommend using the dictionaries provided in your materials package.
How do I get a list of available contracts?
Send a SecurityListRequest (35=x) on your Market Data session. ElectronX will respond with a SecurityList (35=y) containing all currently active symbols. Contract symbols include the specific delivery date and hour and must be exact.
Where do I get help if I run into a connection issue?
Email support@electronx.com. When reporting a connection issue, include your SenderCompID, a description of the error (or the FIX log excerpt if available), and confirmation of which environment you are connecting to (Beta or Production).
Educational content only — not investment advice. This document and all ElectronX materials are subject to the EXI Rulebook and EXI Legal Notices and Disclosures at electronx.com/regulatory.
If there is any conflict between this website page and the EXI Rulebook, the EXI Rulebook is controlling. Refer to electronx.com/risk-disclosure for full risk disclosures.