Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
developers:markets [2025/04/10 21:14] – chad | developers:markets [2025/04/10 21:30] (current) – chad | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
The T4 system uses MarketID to uniquely identify tradeable instruments on our platform. These instruments are partitioned in a hierarchical manner using: | The T4 system uses MarketID to uniquely identify tradeable instruments on our platform. These instruments are partitioned in a hierarchical manner using: | ||
Line 11: | Line 11: | ||
< | < | ||
+ | ===== Authentication ===== | ||
+ | |||
+ | The Market Data API supports two authentication methods, depending on your integration scenario: | ||
+ | |||
+ | * **AuthKey Authentication**: | ||
+ | * **JWT Authentication**: | ||
+ | |||
+ | ==== JWT Authentication ==== | ||
+ | |||
+ | To obtain a JWT token: | ||
+ | |||
+ | - Send a JWT request Protocol Buffer message to the authentication endpoint | ||
+ | - The server will respond with a JWT token that should be included in subsequent API requests | ||
+ | - Include the JWT token in the Authorization header using the Bearer scheme | ||
+ | |||
+ | ==== AuthKey Authentication ==== | ||
+ | |||
+ | For B2B integrations: | ||
+ | |||
+ | - Use your provided AuthKey for direct API access | ||
+ | - Include the AuthKey in the request header as specified in the API documentation | ||
+ | - AuthKeys have configurable permissions and can be managed through the administration portal | ||
+ | |||
+ | ===== Swagger API Documentation ===== | ||
+ | |||
+ | For a complete reference of all available endpoints, request parameters, and response formats, please refer to our interactive Swagger documentation: | ||
+ | |||
+ | [[https:// | ||
Line 302: | Line 330: | ||
+ | ====== Market Picker Endpoints ====== | ||
+ | |||
+ | The Market Picker endpoints provide an efficient way to navigate and select markets, particularly for options markets that may contain thousands of individual instruments. Rather than loading all market definitions at once, these endpoints enable hierarchical browsing and targeted retrieval of market data. | ||
+ | |||
+ | ===== Benefits of the Market Picker Approach ===== | ||
+ | |||
+ | * Performance Optimization: | ||
+ | * Efficient Navigation: Provides a structured approach to browse complex market hierarchies | ||
+ | * Reduced Bandwidth: Retrieves only the necessary market data when needed | ||
+ | * Improved User Experience: Enables faster application load times and responsive market selection | ||
+ | |||
+ | ===== Available Endpoints ===== | ||
+ | |||
+ | ====== Market Groups ====== | ||
+ | |||
+ | The **Market Groups** API endpoint retrieves groupings of markets based on strategy type and expiry date, particularly useful for building hierarchical market selection interfaces. | ||
+ | |||
+ | ==== API Endpoint ==== | ||
+ | < | ||
+ | |||
+ | ==== Header ==== | ||
+ | Include **Authorization** which should contain a valid bearer token. | ||
+ | < | ||
+ | |||
+ | ==== Parameters ==== | ||
+ | ^ Parameter | ||
+ | | exchangeID | ||
+ | | contractID | ||
+ | |||
+ | ==== Response ==== | ||
+ | The response provides groups of markets organized by strategy type. For options, outright markets are further grouped by expiry date. The response includes count of markets in each group. | ||
+ | |||
+ | ==== Use Case ==== | ||
+ | * Building the top level of a hierarchical market picker | ||
+ | * Allowing users to navigate to specific market types or expiry periods | ||
+ | * Displaying summary information about available markets | ||
+ | |||
+ | |||
+ | ====== Market List ====== | ||
+ | |||
+ | The **Market List** API endpoint retrieves a filtered list of markets based on specified criteria, providing essential information for market selection. | ||
+ | |||
+ | ==== API Endpoint ==== | ||
+ | < | ||
+ | |||
+ | ==== Header ==== | ||
+ | Include **Authorization** which should contain a valid bearer token. | ||
+ | < | ||
+ | |||
+ | ==== Parameters ==== | ||
+ | ^ Parameter | ||
+ | | exchangeID | ||
+ | | contractID | ||
+ | | strategyType | ||
+ | | expiryDate | ||
+ | |||
+ | ==== Response ==== | ||
+ | The response is a list of markets matching the filter criteria. Each market includes MarketID, ExpiryDescription, | ||
+ | |||
+ | ==== Use Case ==== | ||
+ | * Displaying markets after a user selects a specific group | ||
+ | * Populating selection dropdowns or lists with available markets | ||
+ | * Enabling users to browse markets with specific characteristics | ||
+ | |||
+ | |||
+ | ====== First Market ====== | ||
+ | |||
+ | The **First Market** API endpoint retrieves the first available market matching specified criteria, typically used to find the front-month contract. | ||
+ | |||
+ | ==== API Endpoint ==== | ||
+ | < | ||
+ | |||
+ | ==== Header ==== | ||
+ | Include **Authorization** which should contain a valid bearer token. | ||
+ | < | ||
+ | |||
+ | ==== Parameters ==== | ||
+ | ^ Parameter | ||
+ | | exchangeID | ||
+ | | contractID | ||
+ | | contractType | ||
+ | | strategyType | ||
+ | |||
+ | ==== Response ==== | ||
+ | The response provides a complete market definition for the first matching market. Markets are ordered according to standard market details comparison. | ||
+ | |||
+ | ==== Use Case ==== | ||
+ | * Automatically selecting the front-month contract | ||
+ | * Setting a default market when a user first accesses a trading interface | ||
+ | * Quick access to the most liquid or commonly traded market in a group | ||
+ | |||
+ | |||
+ | ====== Next Market ====== | ||
+ | |||
+ | The **Next Market** API endpoint finds the next market in sequence after a specified market, maintaining the same contract and strategy types. | ||
+ | |||
+ | ==== API Endpoint ==== | ||
+ | < | ||
+ | |||
+ | ==== Header ==== | ||
+ | Include **Authorization** which should contain a valid bearer token. | ||
+ | < | ||
+ | |||
+ | ==== Parameters ==== | ||
+ | ^ Parameter | ||
+ | | exchangeID | ||
+ | | contractID | ||
+ | | marketID | ||
+ | |||
+ | ==== Response ==== | ||
+ | The response provides a complete market definition for the next market in sequence. Returns 404 if there is no next market. | ||
+ | |||
+ | ==== Use Case ==== | ||
+ | * Implementing " | ||
+ | * Allowing users to iterate through available markets | ||
+ | * Cycling through markets with the same characteristics | ||
+ | |||
+ | |||
+ | ====== Next Expiry ====== | ||
+ | |||
+ | The **Next Expiry** API endpoint locates the next market with a later expiry date than the specified market, while maintaining the same contract and strategy types. | ||
+ | |||
+ | ==== API Endpoint ==== | ||
+ | < | ||
+ | |||
+ | ==== Header ==== | ||
+ | Include **Authorization** which should contain a valid bearer token. | ||
+ | < | ||
+ | |||
+ | ==== Parameters ==== | ||
+ | ^ Parameter | ||
+ | | exchangeID | ||
+ | | contractID | ||
+ | | marketID | ||
+ | |||
+ | ==== Response ==== | ||
+ | The response provides a complete market definition for the next expiry market. Returns 404 if there is no market with a later expiry. | ||
+ | ==== Use Case ==== | ||
+ | * Rolling positions forward to the next expiry period | ||
+ | * Comparing markets across different expiry dates | ||
+ | * Analyzing term structure or calendar spreads | ||