developers:legacy_fix_api

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
developers:legacy_fix_api [2025/08/12 12:19] – robdevelopers:legacy_fix_api [2025/08/15 18:41] (current) – rob
Line 1: Line 1:
-====== T4 FIX API ======+==== T4 FIX API ====
  
-Click to enable email notifications for this page+This document outlines how to use the T4 FIX API 4.0 of Plus500US Futures Technologies, LLC. The T4 FIX API conforms to the [[http://www.fixprotocol.org|Financial Information eXchange (FIX) Protocol]] with minor improvements and customizations as presented herein.
  
-This document outlines how to use the **T4 FIX API 4.0** of Plus500US Futures Technologies, LLC. The T4 FIX API conforms to the Financial Information eXchange (FIX) Protocol with minor improvements and customizations as presented herein.+<WRAP center round important 100%> 
 +**T4 FIX API applications cannot be run simultaneously with our frontend or other applications with the same username. If you are creating an application that needs to be run simultaneously with other applications under the same username then you should use the Microsoft .Net based T4 API as that will allow simultaneous logins from the same physical machine.** 
 +</WRAP>
  
-T4 FIX API applications cannot be run simultaneously with our frontend or other applications with the same username. If you are creating an application that needs to be run simultaneously with other applications under the same username then you should use the Microsoft .Net based T4 API as that will allow simultaneous logins from the same physical machine. 
  
 To develop to the T4 FIX API, you need a dedicated SSL connection to a T4 FIX API server. Your FIX client will negotiate a socket TCP connection and authenticate login parameters. To assist in development, we can provide a FIX Simulator system with market depth and execution 24x5, regardless of real market hours. From the FIX API’s perspective, the FIX Simulator works exactly the same as a live FIX system. To develop to the T4 FIX API, you need a dedicated SSL connection to a T4 FIX API server. Your FIX client will negotiate a socket TCP connection and authenticate login parameters. To assist in development, we can provide a FIX Simulator system with market depth and execution 24x5, regardless of real market hours. From the FIX API’s perspective, the FIX Simulator works exactly the same as a live FIX system.
  
-Please note that changes in documentation may precede availability of changes in production by a few weeks. Also note that new tags and tag values can be added to the Message Dictionary of FIX messages without prior notification. T4 FIX API applications must be coded with appropriate flexibility (e.g. exception handling) to handle changes in FIX message schemas.+<WRAP center round alert 100%> 
 +**Please note that changes in documentation may precede availability of changes in production by a few weeks. Also note that new tags and tag values can be added to the _Message Dictionary_ of FIX messages without prior notification. T4 FIX API applications must be coded with appropriate flexibility (e.g. exception handling) to handle changes in FIX message schemas.** 
 +</WRAP>
  
-===== FIX Session ===== 
  
-In the following scenarios, the T4 API User (Client) is identified as the **Initiator** while the T4 FIX API (Server) is named the **Acceptor**.   +===== FIX Session =====
-Under the FIX API, a FIX session is comprised of a FIX Logon, (administrative and application) message exchanges and a FIX Logout. Under all circumstances, a FIX session spans over these 3 components. Note, the FIX session does not span over multiple FIX Logons.+
  
-In the T4 FIX API, all (application level) message interactions are governed by the FIX Session Protocol rules as applied to both administrative and application messages.   +In the following scenarios, the T4 API User (Client) is identified as the “Initiator” while the T4 FIX API (Server) is named the “Acceptor”. Under the FIX API, a FIX session is comprised of a [[developers:fixapi.logon|FIX Logon]], (administrative and application) message exchanges and a [[developers:fixapi.logout|FIX Logout]]. Under all circumstances, a FIX session spans over these 3 components. Note, the FIX session does not span over multiple [[developers:fixapi.logon|FIX Logons]]. In the T4 FIX API, all (application level) message interactions are governed by the FIX Session Protocol rules as applied to both administrative and application messages. As an option of the FIX API, the FIX Session may also include multiple [[developers:fixapi.traderlogon|Trader Logons]]. This feature accommodates multiple Traders/Users under the same physical connection of the FIX Session.
-As an option of the FIX API, the FIX Session may also include multiple Trader Logons. This feature accommodates multiple Traders/Users under the same physical connection of the FIX Session.+
  
 ===== Message Integrity ===== ===== Message Integrity =====
  
-The integrity of the FIX messages is of primary importance to maintain a FIX Session under the T4 FIX API.   +The integrity of the FIX messages is of primary importance to maintain a FIX Session under the T4 FIX API. All messages must be well-formed (non-garbled and complete), delineated with the SOH delimiter character (ASCII 001), with no empty tags, carry valid value types and be in faithful conformance to the message (Tag) dictionaries of this current documentation. All messages must be delivered in sequential order as specified by the Sequence Number tag (Tag 34). Data integrity must be signed by the message CheckSum number (Tag 10). Unless specified as part of the T4 FIX API dictionaries, custom tags will be ignored and may cause a FIX Session termination. All message traffic is un-encrypted.
-All messages must be: +
-  * Well-formed (non-garbled and complete) +
-  * Delineated with the SOH delimiter character (ASCII 001) +
-  * With no empty tags +
-  * Carry valid value types +
-  * In faithful conformance to the message (Tag) dictionaries of this current documentation+
  
-All messages must be delivered in sequential order as specified by the **Sequence Number** tag (Tag 34).   +===== Message Structure =====
-Data integrity must be signed by the message **CheckSum** number (Tag 10).  +
  
-Unless specified as part of the T4 FIX API dictionaries, custom tags will be ignored and may cause a FIX Session termination.   +All messages (administrative and application) are expected to conform to the __FIX 4.2__ (Tag-Value) format with __minor improvements and customizations__. In addition to the mandatory FIX [[developers:fixapi.standardheader|Standard Header]] and [[developers:fixapi.standardtrailer|Standard Trailer]], messages received through a client connection are required to be fully compliant with the T4 FIX API **Message Dictionary** (as shown from the **Message Types** links below). All messages must contain BeginString (Tag 8), BodyLength (Tag 9) and MessageType (Tag 35) as the first 3 tags. The [[developers:fixapi.standardtrailer|Standard Trailer]] must also contain a correctly computed CheckSum number (Tag 10). Messages deviated from the above will be considered as garbled. Upon the detection of a garbled message, the current FIX Session will be subject to immediate termination. The TCP physical connection will also be dropped.
-All message traffic is un-encrypted.+
  
-===== Message Structure =====+For sample and details of specific FIX messages, please refer to the description of each message type below. Note that the sample FIX messages are provided without the mandatory tags BeginString (Tag 8), MessageType (Tag 35), MessageLength (Tag 9) and CheckSum (Tag 10). For brevity, all message dictionaries are only provided with the **relevant T4** tags.
  
-All messages (administrative and application) are expected to conform to the **FIX 4.2 (Tag-Value)** format with minor improvements and customizations.+Under the T4 FIX API, securities are uniquely identified by the specific market of a contract offered by an exchange. As such, Exchanges are identified by a unique Exchange ID in Tag 207 (SecurityExchange). Contracts are characterized by its Contract ID in Tag 55 (Symbol). Markets are identified by a unique Market ID in Tag 48 (SecurityID).
  
-In addition to the mandatory FIX **Standard Header** and **Standard Trailer**, messages received through a client connection are required to be fully compliant with the T4 FIX API ''Message Dictionary'' (as shown from the ''Message Types'' links below).+===== Message Types =====
  
-All messages must contain: +For a full explanation of message type dynamics and its corresponding tag dictionary, please click on the links below.
-  - **BeginString** (Tag 8) +
-  - **BodyLength** (Tag 9) +
-  - **MessageType** (Tag 35)   +
-    as the first 3 tags.+
  
-The Standard Trailer must also contain a correctly computed **CheckSum** number (Tag 10).   +^ **ADMINISTRATIVE**             ^ **MARKET DATA**                  ^ **SECURITY DEFINITIONS**          ^ **ORDER ROUTING**                   ^ **APPLICATION MANAGEMENT**         ^ 
-Messages deviated from the above will be considered as garbled. Upon detection of a garbled message, the current FIX Session will be subject to immediate termination. The TCP physical connection will also be dropped.+| [[developers:fixapi.logon|Logon]]                  | [[developers:fixapi.marketdatarequest|MarketData Request]]          | [[developers:fixapi.securitydefinitionrequest|Security Definition Request]] | [[developers:fixapi.newordersingle|New Order Single]]          | [[developers:fixapi.collateralinquiry|Collateral Inquiry]]      | 
 +| [[developers:fixapi.logout|Logout]]                | [[developers:fixapi.marketdatasnapshotfullrefresh|MarketData Snapshot FullRefresh]] | [[developers:fixapi.securitydefinition|Security Definition]]       | [[developers:fixapi.cancelreplacerequest|Cancel Replace Request]]| [[developers:fixapi.collateralreport|Collateral Report]]         | 
 +| [[developers:fixapi.heartbeat|Heartbeat]]          | [[developers:fixapi.marketdataincrementalrefresh|MarketData Incremental Refresh]] |                                                          | [[developers:fixapi.ordercancelrequest|Order Cancel Request]]    |                                                               | 
 +| [[developers:fixapi.testrequest|Test Request]]     | [[developers:fixapi.marketdatarequestreject|MarketData Request Reject]]     |                                                          | [[developers:fixapi.executionreport|Execution Report]]           |                                                               | 
 +| [[developers:fixapi.resendrequest|Resend Request]] |                                                          |                                                          | [[developers:fixapi.orderstatusrequest|Order Status Request]]    |                                                               | 
 +| [[developers:fixapi.sequencereset|Sequence Reset]] |                                                          |                                                          | [[developers:fixapi.cancelreject|Cancel Reject]]                 |                                                               | 
 +| [[developers:fixapi.reject|Reject]]                |                                                          |                                                          | [[developers:fixapi.neworderlist|New Order List]]                |                                                               | 
 +| [[developers:fixapi.traderlogon|Trader Logon]]    |                                                          |                                                          | [[developers:fixapi.listcancelrequest|List Cancel Request]]      |                                                               | 
 +| [[developers:fixapi.traderlogonresponse|Trader Logon Response]] |                                                          |                                                          | [[developers:fixapi.ordermassstatusrequest|Order Mass Status Request]] |                                                               | 
 +| [[developers:fixapi.traderlogout|Trader Logout]]  |                                                          |                                                          |                                                               |                                                               | 
 +| [[developers:fixapi.traderlogoutresponse|Trader Logout Response]] |                                                          |                                                          |                                                               |                                                               |
  
-For sample and details of specific FIX messages, please refer to the description of each message type below.   +===== Order Types =====
-Note that the sample FIX messages are provided without the mandatory tags: +
-  * **BeginString** (Tag 8) +
-  * **MessageType** (Tag 35) +
-  * **MessageLength** (Tag 9) +
-  * **CheckSum** (Tag 10)+
  
-For brevity, all message dictionaries are only provided with the relevant T4 tags.+The T4 FIX API supports a comprehensive set of Order Types for Order Routing. Please click on the links below for a full explanation and sample messages.
  
-Under the T4 FIX API: +^ **STANDARD**                        ^ **SPECIAL**                              ^ **CONTINGENT (BATCH)**                       ^ 
-  * Securities are uniquely identified by the specific market of a contract offered by an exchange. +| [[developers:fixapi.marketorder|Market]]                     | [[developers:fixapi.completevolumeorder|Complete Volume]]                 | [[developers:fixapi.ocoorder|OCO (One Cancels Other)]]           | 
-  * Exchanges are identified by a unique **Exchange ID** in Tag 207 (SecurityExchange). +| [[developers:fixapi.limitorder|Limit]]                       | [[developers:fixapi.immediateandcancelorder|Immediate And Cancel]]         | [[developers:fixapi.autoocoorder|Automatic OCO (One Cancels Other)]] | 
-  * Contracts are characterized by its **Contract ID** in Tag 55 (Symbol). +| [[developers:fixapi.stoporder|Stop]]                         | [[developers:fixapi.gtcorder|Good Til Cancel]]                            | [[developers:fixapi.spark|Spark]]                                 | 
-  * Markets are identified by a unique **Market ID** in Tag 48 (SecurityID).+| [[developers:fixapi.stoplimitorder|Stop Limit]]               | [[developers:fixapi.activationonmarketmodeorder|Activation On Market Mode]]| [[developers:fixapi.autoocom|Automatic OCO (Multiple Exits)]]     | 
 +| [[developers:fixapi.trailingstoporder|Trailing Stop]]         | [[developers:fixapi.activationattimeorder|Activation At Time]]            |                                                               | 
 +|                                                                  | [[developers:fixapi.activationonpriceorder|Activation On Price]]          |                                                               | 
 +|                                                                  | [[developers:fixapi.flattenorder|Flatten]]                                |                                                               | 
 +|                                                                  | [[developers:fixapi.joinorder|Join]]                                      |                                                               | 
 +|                                                                  | [[developers:fixapi.hitorder|Hit]]                                        |                                                               | 
 +|                                                                  | [[developers:fixapi.queueorder|Queue]]                                    |                                                               | 
 +|                                                                  | [[developers:fixapi.marketiftouchedorder|Market If Touched]]              |                                                               |
  
-===== Message Types ===== 
  
-For a full explanation of message type dynamics and its corresponding tag dictionary, see:+===== System Access =====
  
-**Administrative** :: +In the early stages of development we ask that developers make use of the license provided in our examples. This allows access to some Dummy markets so that you can subscribe for quotes and submit orders. To access real markets, such as the CME, you have to request a Simulation license code.
-  * Logon +
-  * Logout +
-  * Heartbeat +
-  * Test Request +
-  * Resend Request +
-  * Sequence Reset +
-  * Reject +
-  * Trader Logon +
-  * Trader Logon Response +
-  * Trader Logout +
-  * Trader Logout Response+
  
-**Market Data** :: +If at any time you require assistance from CTS you must send in your FIX messages to [email protected].   
-  * MarketData Request +Our API support will not answer if the messages aren't delimited in a reasonable way for readability.
-  * MarketData Snapshot FullRefresh +
-  * MarketData Incremental Refresh +
-  * MarketData Request Reject+
  
-**Security Definitions** :: +To request production live and/or Simulator license codes please provide the following information to **your clearing firm**.   
-  * Security Definition Request +Your clearing firm is then required to provide [email protected] with their informal approval and the details you have provided. 
-  * Security Definition+ 
 +^ Field         ^ Description                                                                                                                ^ 
 +| Live Firm     | The live firm used as part of user authentication.                                                                         | 
 +| Live Users    | All Live users that require access to this application. Configuration of Live users will be completed by your broker or FCM. CTS is not permitted to configure Live users. | 
 +| Sim Firm      | The Simulation firm used as part of user authentication.                                                                   | 
 +| Sim Users     | All Simulation users that require access to this application.                                                              | 
 +| Application   | Name of your application. This needs to be unique across our system so it should be prefixed with your company initials or similar. Please do not include "T4", "CTS" or "Cunningham" in your application name. | 
 +| Developer     | Name of the developer or person responsible for the application.                                                           | 
 +| Email         | Email address for the developer                                                                                            | 
 +| Phone         | Phone number for the developer                                                                                             | 
 + 
 +You will then be provided with a license code that your application will need to use every time it logs in.   
 +Please note that the license code will be different for the Live and Simulator systems. 
 + 
 +If you are creating multiple applications then you should request a license for each application.   
 +If your application causes the system problems (e.g. excessive load) then we may be forced to disable it. 
 + 
 +We strongly encourage developers to create a single application to satisfy all of their needs.   
 +Same as our front-end sits on a single instance of the API and yet offers many different types of functionality.   
 +Running multiple applications increases bandwidth usage and overall overhead on our system. 
 + 
 +To connect your application to T4 you would need to establish an SSL connection to the appropriate system below: 
 + 
 +^ System     ^ URL                   ^ Port  ^ 
 +| Simulator  | fix-sim.t4login.com    | 10443 | 
 +| Live       | fix.t4login.com        | 10443 | 
 + 
 +We have the following IP address ranges: 
 + 
 +  * **Internap - EQ-CER Range**: 74.201.6.0 /24 Mask: 255.255.255.0 
 +  * **CenturyLink - EQ-CER Range**: 69.44.110.0 /24 Mask: 255.255.255.0 
 + 
 +Our applications use port 80 & 443 on any of those IP’s.   
 +From a domain name perspective you need: 
 +  * *.t4login.com 
 +  * *.sim.t4login.com 
 +  * www.ctsfutures.com 
 + 
 +If your proxy requires authentication then you will need to allow T4 to bypass it as the Microsoft .Net Framework we use doesn’t support authenticating proxy servers.   
 +If your proxy doesn’t require authentication then T4 should work fine, but if it doesn’t then the simplest solution would be to bypass the proxy if that is possible. 
 + 
 +===== PING ===== 
 + 
 +We don’t enable ping or tracert across our entire system.   
 +You can ping **64.74.232.69**.   
 +It is a device on the edge of our network. 
 + 
 + 
 +===== FIX Basics ===== 
 + 
 +The T4 FIX API conforms to the Financial Information eXchange (FIX) Protocol with minor improvements and customizations.   
 +Documentation on FIX can be found at: http://www.fixprotocol.org 
 + 
 +==== Requirements ==== 
 +To develop to the T4 FIX API, you need a dedicated SSL connection to a T4 FIX API server.   
 +Your FIX client will negotiate a socket TCP connection and authenticate login parameters.   
 + 
 +To assist in development, we can provide a FIX Simulator system with market depth and execution **24x5**, regardless of real market hours.   
 +From the FIX API’s perspective, the FIX Simulator works exactly the same as a live FIX system. 
 + 
 +==== FIX Technology ==== 
 +FIX is a messaging protocol for executing electronic transactions between financial institutions under a common framework.   
 +A good overview on FIX can be found here: http://www.fixtradingcommunity.org/pg/main/what-is-fix 
 + 
 +==== FIX Protocol Resources ==== 
 +A good source of FIX information, documentation, official protocol specifications, and message examples (including implementation source code) can be found at the protocol’s guardian:   
 +http://www.fixtradingcommunity.org 
 + 
 +==== FIX Complementary Resources ==== 
 +For beginners, QuickFIX is commonly recommended as it simplifies some FIX implementation details and has several source code examples:   
 +http://www.quickfixengine.org/quickfix/doc/html 
 + 
 +As the T4 FIX API communications are encrypted with SSL (Secured Sockets Layer), an SSL proxy (e.g. Stunnel) may be used to cover the SSL requirement:   
 +https://www.stunnel.org/ 
 + 
 +==== T4 FIX API Documentation and Samples ==== 
 +T4 FIX API is based on the most commonly used version in the industry: **FIX version 4.2**.   
 +It further provides enhancements with minor customizations. 
 + 
 +With many message examples, the full documentation of T4 FIX API can be found here:   
 +http://www.t4login.com/wiki/T4FIXAPI 
 + 
 +Exercising most T4 FIX API capabilities, an extensive source code example based on Microsoft .Net and QuickFIX can be found in: **FIXEXampleQF**
  
-**Order Routing** :: 
-  * New Order Single 
-  * Cancel Replace Request 
-  * Order Cancel Request 
-  * Execution Report 
-  * Order Status Request 
-  * Cancel Reject 
-  * New Order List 
-  * List Cancel Request 
-  * Order Mass Status Request 
  
-**Application Management** :: 
-  * Collateral Inquiry 
-  * Collateral Report 
  
-===== Order Types ===== 
  
-The T4 FIX API supports a comprehensive set of Order Types for Order Routing.+**Note**: To complement this current T4 FIX API documentation, the FIX Protocol Version 4.2 standard can be located at the [[http://www.fixprotocol.org|FIX Protocol organization web site]].
  
-**Standard** :: +<WRAP info round box 100%> 
-  * Market +====== Step 1: Start Your Certification ====== 
-  * Limit +**Email:** [[[email protected]]]  
-  * Stop +  
-  * Stop Limit +**Include:** A clear description of what your application will do.
-  * Trailing Stop +
-  * Complete Volume +
-  * Immediate And Cancel +
-  * Good Til Cancel+
  
-**Special** :: +**What happens next:** 
-  * Activation On Market Mode +  - **We review your submission** to determine if the exchange needs to be involved.    
-  * Activation At Time +  - **Possible exchange review** – in some cases, you may need to contact the exchange for their certification.   
-  * Activation On Price +  - **Application form sent** – once all reviews are complete, we’ll email you the official application form to fill out.   
-  * Flatten +  - **Guided setup** – once we receive your completed form, we will walk you through the setup process step-by-step. 
-  * Join +</WRAP>
-  * Hit +
-  * Queue +
-  * Market If Touched +
-  * OCO (One Cancels Other) +
-  * Automatic OCO (One Cancels Other) +
-  * Spark +
-  * Automatic OCO (Multiple Exits)+
  
----- 
  
-**Note:** To complement this current T4 FIX API documentation, the FIX Protocol Version 4.2 standard can be located at the FIX Protocol organization web site. 
  
  • developers/legacy_fix_api.1755001191.txt.gz
  • Last modified: 2025/08/12 12:19
  • by rob