Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
developers:fixapi:start [2025/09/12 01:33] – chad | developers:fixapi:start [2025/09/12 02:36] (current) – chad | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== T4 FIX API ==== | + | ====== T4 FIX API OVERVIEW ====== |
- | This document outlines how to use the T4 FIX API 4.0 of Plus500US Futures Technologies, | + | The T4 FIX API 4.0 provides electronic trading access |
- | To develop to the T4 FIX API, you need a dedicated | + | ===== Connection Requirements ===== |
+ | * SSL-encrypted TCP socket connection | ||
+ | * Authentication via FIX Logon | ||
- | ===== FIX Session ===== | + | ===== FIX Session |
+ | 1. [[developers: | ||
+ | 2. **Message Exchange** - Trading and market data | ||
+ | 3. [[developers: | ||
- | 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: | + | Optional: Multiple |
- | ===== Message Integrity ===== | + | ===== Message Integrity |
+ | * SOH delimiter (ASCII 001) between fields | ||
+ | * Sequential message numbering (Tag 34) | ||
+ | * Valid CheckSum (Tag 10) | ||
+ | * No empty tags | ||
+ | * Conformance to T4 message dictionaries | ||
- | 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, | + | ===== Market Identification |
- | + | ^ Field ^ Tag ^ Description ^ | |
- | ===== Message Structure | + | | SecurityExchange |
- | + | | Symbol | 55 | Contract identifier | | |
- | 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: | + | | SecurityID | 48 | Unique |
- | + | ||
- | 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. | + | |
- | + | ||
- | Under the T4 FIX API, securities are uniquely identified by the specific | + | |
===== Message Types ===== | ===== Message Types ===== | ||
- | For a full explanation of message type dynamics and its corresponding tag dictionary, please click on the links below. | + | ^ **ADMINISTRATIVE** ^ **MARKET DATA** ^ **SECURITY DEFINITIONS** ^ **ORDER ROUTING** ^ **APPLICATION MANAGEMENT** ^ |
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
+ | | [[developers: | ||
- | ^ **ADMINISTRATIVE** | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
===== Order Types ===== | ===== Order Types ===== | ||
- | 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. | + | ^ **STANDARD** ^ **SPECIAL** ^ **CONTINGENT (BATCH)** ^ |
- | + | | [[developers: | |
- | ^ **STANDARD** | + | | [[developers: |
- | | [[developers: | + | | [[developers: |
- | | [[developers: | + | | [[developers: |
- | | [[developers: | + | | [[developers: |
- | | [[developers: | + | | | [[developers: |
- | | [[developers: | + | | | [[developers: |
- | | | [[developers: | + | | | [[developers: |
- | | | [[developers: | + | | | [[developers: |
- | | | [[developers: | + | | | [[developers: |
- | | | [[developers: | + | | | [[developers: |
- | | | [[developers: | + | |
- | | | [[developers: | + | |
- | + | ||
- | + | ||
- | ===== System Access ===== | + | |
- | + | ||
- | 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. | + | |
- | + | ||
- | <WRAP center round alert 100%> | + | |
- | If at any time you require assistance from CTS you must send in your FIX messages to T4 API Support < | + | |
- | Our API support will not answer if the messages aren't delimited in a reasonable way for readability. | + | |
- | </ | + | |
- | To request production live and/or Simulator license codes please provide the following information. | + | |
- | + | ||
- | **Start Your Certification** | + | |
- | **Email:** [[[email protected]]] | + | |
- | + | ||
- | **Include: | + | |
- | + | ||
- | **What happens next:** | + | |
- | - **We review your submission** to determine if the exchange needs to be involved. | + | |
- | - **Possible exchange review** – in some cases, you may need to contact the exchange for their certification. | + | |
- | - **Application form sent** – once all reviews are complete, we’ll email you the official application form to fill out. | + | |
- | - **Guided setup** – once we receive your completed form, we will walk you through the setup process step-by-step. | + | |
- | + | ||
- | + | ||
- | + | ||
- | <WRAP center round important 100%> | + | |
- | * 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 | + | |
- | | Simulator | + | |
- | | Live | fix.t4login.com | + | |
- | + | ||
- | 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:// | + | |
- | + | ||
- | ==== 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, | + | |
- | From the FIX API’s perspective, | + | |
- | + | ||
- | ==== 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:// | + | |
- | + | ||
- | ==== FIX Protocol Resources ==== | + | |
- | A good source of FIX information, | + | |
- | http:// | + | |
- | + | ||
- | ==== FIX Complementary Resources ==== | + | |
- | For beginners, QuickFIX is commonly recommended as it simplifies some FIX implementation details and has several source code examples: | + | |
- | http:// | + | |
- | + | ||
- | 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:// | + | |
- | + | ||
- | ==== 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:// | + | |
- | + | ||
- | Exercising most T4 FIX API capabilities, | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | **Note**: To complement this current T4 FIX API documentation, | + | |
- | + | ||
+ | ===== Resources ===== | ||
+ | * **FIX Protocol:** http:// | ||
+ | * **FIX Community: | ||
+ | * **QuickFIX Engine:** http:// | ||
+ | * **SSL Proxy (Stunnel): | ||
+ | * **Base Version:** FIX 4.2 |