Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
faq:faq_fix_api_test [2025/01/03 19:17] – created rob | faq:faq_fix_api_test [2025/01/15 13:54] (current) – rob | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Test ====== | + | ==== T4 FIX API ==== |
+ | |||
This document outlines how to use the T4 FIX API 4.0 of Plus500US Futures Technologies, | This document outlines how to use the T4 FIX API 4.0 of Plus500US Futures Technologies, | ||
Line 6: | Line 8: | ||
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, | 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, | ||
- | **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* | + | **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_ |
==== FIX Session ==== | ==== 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”. Under the FIX API, a FIX session is comprised of a [[Logon|FIX Logon]], (administrative and application) message exchanges and a [[Logout|FIX Logout]]. Under all circumstances, | 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 [[Logon|FIX Logon]], (administrative and application) message exchanges and a [[Logout|FIX Logout]]. Under all circumstances, | ||
==== Message Integrity ==== | ==== Message Integrity ==== | ||
+ | |||
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, | 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, | ||
==== Message Structure ==== | ==== Message Structure ==== | ||
- | 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 [[Standard Header|Standard Header]] and [[Standard Trailer|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 [[Standard Trailer|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. | ||
- | For sample and details of specific FIX messages, please refer to the description of each message type below. Note that the sample | + | All messages |
- | 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 an unique Exchange ID in Tag 207 (SecurityExchange). Contracts are characterized by its Contract ID in Tag 55 (Symbol). Markets are identified by an unique Market ID in Tag 48 (SecurityID). | + | 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 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). | ||
==== Message Types ==== | ==== Message Types ==== | ||
+ | |||
For a full explanation of message type dynamics and its corresponding tag dictionary, please click on the links below. | For a full explanation of message type dynamics and its corresponding tag dictionary, please click on the links below. | ||
- | | + | ^ **ADMINISTRATIVE** |
- | | [[Logon|Logon]] | [[MarketData Request|MarketData Request]] | [[Security Definition Request|Security Definition Request]] | [[New Order Single|New Order Single]] | [[Collateral Inquiry|Collateral Inquiry]] | | + | | [[Logon|Logon]] | [[MarketData Request|MarketData Request]] | [[Security Definition Request|Security Definition Request]] | [[Order Single|New Order Single]] | [[Collateral Inquiry|Collateral Inquiry]] | |
- | | [[Logout|Logout]] | [[MarketData Snapshot FullRefresh|MarketData Snapshot FullRefresh]] | [[Security Definition|Security Definition]] | [[Cancel | + | | [[Logout|Logout]] | [[MarketData Snapshot FullRefresh|MarketData Snapshot FullRefresh]] | [[Security Definition|Security Definition]] | [[Order Cancel |
- | | [[Heartbeat|Heartbeat]] | [[MarketData Incremental Refresh|MarketData Incremental Refresh]] | | [[Execution Report|Execution Report]] | | + | | [[Heartbeat|Heartbeat]] | [[MarketData Incremental Refresh|MarketData Incremental Refresh]] | | [[Order Cancel Request|Order Cancel Request]] | | |
- | | [[Test Request|Test Request]] | [[MarketData Request Reject|MarketData Request Reject]] | | [[Order Status Request|Order Status Request]] | | + | | [[Test Request|Test Request]] | [[MarketData Request Reject|MarketData Request Reject]] |
- | | [[Resend Request|Resend Request]] | | | [[Cancel Reject|Cancel Reject]] | | + | | [[Resend Request|Resend Request]] | | | [[Order Status Request|Order Status Request]] |
- | | [[Sequence Reset|Sequence Reset]] | | | [[New Order List|New Order List]] | | + | | [[Sequence Reset|Sequence Reset]] | | | [[Cancel Reject|Cancel Reject]] |
- | | [[Reject|Reject]] | | | [[List Cancel Request|List Cancel Request]] | | + | | [[Reject|Reject]] | | | [[New Order List|New Order List]] |
- | | [[TraderLogon|Trader Logon]] | | | [[Order Mass Status Request|Order Mass Status Request]] | + | | [[TraderLogon|Trader Logon]] | | | [[List Cancel Request|List Cancel Request]] |
- | | [[TraderLogonResponse|Trader Logon Response]] | | | | | + | | [[TraderLogonResponse|Trader Logon Response]] | | | [[Order Mass Status Request|Order Mass Status Request]] | | |
- | | [[TraderLogout|Trader Logout]] | | | | | + | | [[TraderLogout|Trader Logout]] |
- | | [[TraderLogoutResponse|Trader Logout Response]] | | | | | + | | [[TraderLogoutResponse|Trader Logout Response]] |
==== 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. | 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** |
- | | [[Market|Market]] | [[Complete Volume|Complete Volume]] | [[OCO (One Cancels Other)|OCO (One Cancels Other)]] | | + | | [[Market |
- | | [[Limit|Limit]] | [[Immediate And Cancel|Immediate And Cancel]] | [[Automatic OCO (One Cancels Other)|Automatic OCO (One Cancels Other)]] | | + | | [[Limit |
- | | [[Stop|Stop]] | [[Good Til Cancel|Good Til Cancel]] | [[Spark|Spark]] | | + | | [[Stop |
- | | [[Stop Limit|Stop Limit]] | [[Activation On Market Mode|Activation On Market Mode]] | [[Automatic OCO (Multiple Exits)|Automatic OCO (Multiple Exits)]] | | + | | [[Stop Limit Order|Stop Limit]] | [[Activation On Market Mode Order|Activation On Market Mode]] | [[AutoOCOM|Automatic OCO (Multiple Exits)]] | |
- | | [[Trailing Stop|Trailing Stop]] | [[Activation At Time|Activation At Time]] | | | + | | [[Trailing Stop Order|Trailing Stop]] | [[Activation At Time Order|Activation At Time]] | | |
- | | | [[Activation On Price|Activation On Price]] | | | + | | | [[Activation On Price Order|Activation On Price]] | | |
- | | | [[Flatten|Flatten]] | | | + | | | [[Flatten |
- | | | [[Join|Join]] | | | + | | | [[Join |
- | | | [[Hit|Hit]] | | | + | | | [[Hit Order|Hit]] | | |
- | | | [[Queue|Queue]] | | | + | | | [[Queue |
- | | | [[Market If Touched|Market If Touched]] | | | + | | | [[MarketIfTouched Order|Market If Touched]] | | |
- | Note: To complement this current T4 FIX API documentation, | + | **Note**: To complement this current T4 FIX API documentation, |