Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
developers:legacy_fix_api [2025/08/12 18:11] – [Order Types] rob | developers:legacy_fix_api [2025/09/11 18:41] (current) – removed chad | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== T4 FIX API ==== | ||
- | |||
- | This document outlines how to use the T4 FIX API 4.0 of Plus500US Futures Technologies, | ||
- | |||
- | <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.** | ||
- | </ | ||
- | |||
- | |||
- | 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, | ||
- | |||
- | <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.** | ||
- | </ | ||
- | |||
- | |||
- | ===== 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 [[developers: | ||
- | |||
- | ===== 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, | ||
- | |||
- | ===== 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 [[developers: | ||
- | |||
- | 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 ===== | ||
- | |||
- | For a full explanation of message type dynamics and its corresponding tag dictionary, please click on the links below. | ||
- | |||
- | ^ **ADMINISTRATIVE** | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | |||
- | ===== 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** | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | [[developers: | ||
- | | | [[developers: | ||
- | | | [[developers: | ||
- | | | [[developers: | ||
- | | | [[developers: | ||
- | | | [[developers: | ||
- | | | [[developers: | ||
- | |||
- | **Note**: To complement this current T4 FIX API documentation, | ||
- | |||
- | |||
- | |||