Metadata reading is available for any client without any enablements. But it may contain user-specific fields, e.g., ContractMetadata.market_data_delay.
The basic metadata type is ContractMetadata.
Ways to obtain it:
1. By string pattern - SymbolResolutionRequest.
o See the rules in the message description.
o Use case: Client wants to start work with a contract.
2. By contract ID - ContractMetadataRequest.
o Use case: Client app wants to get ContractMetadata, but doesn’t have it in cache.
3. By group ID - InstrumentGroupRequest.
o Use case: Get a list of contracts in the group: list of options or list of futures.
4. InstrumentGroupByExchangeRequest, InstrumentGroupBySecuritiesRequest.
o Use case: Get a list of available exchange strategies (UDS).
5. As part of OrderStatus or PositionStatus, for the first status in the connection with such contract.
o Use case: Immediately process status without an additional request to the server.
6. Result of StrategyDefinitionRequest or InstrumentDefinitionReport.
o Use case: User wants to create/define a contract. It may require special permission.
1-4 support metadata subscriptions, which provide:
•Contract metadata changes
•Contract list modifications (additions/removals)
The fields contract_symbol, title, and description are returned in the CQG dialect.
You can specify a preferred dialect using the Logon.dialect_id or LogonInit.dialect_id field. For a list of available dialects, please contact customer support.
Once a dialect is specified, subsequent SymbolResolutionRequest messages will resolve patterns in that dialect, and the resulting ContractMetadata will include additional dialect_* fields, such as dialect_title.
In addition to the dialect_id specified at logon, you can override it per request by including a dialect_id field in a SymbolResolutionRequest. When this override is used, the following outcomes are possible:
•ContractMetadata is returned with fields populated for the requested dialect.
•ContractMetadata is returned without dialect-specific fields if the pattern cannot be resolved in the requested dialect and a fallback is enabled.
•The resolution fails if the pattern cannot be resolved in the requested dialect and no fallback is configured.
Important: When dialect_id is specified in the request, the system does not fall back to the dialect provided at logon.
Note: Dialect fallback is a server-side setting configured per dialect. When enabled, and resolution in the requested dialect fails, the system will attempt to resolve the pattern using the CQG dialect. Clients cannot control this setting.
If you have an underlying contract and you want to get a list of options for it, first you need to send OptionMaturityListRequest. The report will contain available option maturities with IDs, which can be used in InstrumentGroupRequest to get a list of options (calls and puts).
Information about trading session schedules is available as metadata. Changes are rare and typically occur only when a new set of holidays is created for the future.
For more dynamic information, refer to MarketState.
Note: Pre-open and post-close times are calculated by CQG, meaning that quotes can be received during this period.
Note: Intraday sessions follow the CQG Standard and may differ from exchange schedules, but generally, open/close times remain the same.
SessionTimeRangeRequest allows retrieving intraday sessions with open/close times for a specified period or a set number of sessions since a given time.
Retrieve 3 sessions since LogonResult.base_time (from_utc_time is 0) for EP (where session_info_id is obtained from ContractMetadata during symbol resolution).
Client Message:
{
"information_requests": [
{
"id": 7,
"session_timerange_request": {
"session_info_id": 206,
"from_utc_time": 0,
"count": 3
}
}
]
}
Server Response:
(with additionally converted times)
{
"information_reports": [
{
"id":
7,
"status_code":
0,
"session_timerange_report": {
"session_time_ranges": [
{
"pre_open_utc_time": 57997000 (Sun Feb 16 22:30:00 2025),
"open_utc_time": 59797000 (Sun Feb 16 23:00:00 2025),
"close_utc_time": 115597000 (Mon Feb 17 14:30:00 2025),
"post_close_utc_time": 115597000 (Mon Feb 17 14:30:00
2025),
"trade_date": 149797000 (Tue Feb 18 00:00:00 2025),
"session_name": "Globex Night"
},
{
"pre_open_utc_time": 115597000 (Mon Feb 17 14:30:00
2025),
"open_utc_time": 115597000 (Mon Feb 17 14:30:00 2025),
"close_utc_time": 128197000 (Mon Feb 17 18:00:00 2025),
"post_close_utc_time": 139897000 (Mon Feb 17 21:15:00
2025),
"trade_date": 149797000 (Tue Feb 18 00:00:00 2025),
"session_name": "Globex Day"
},
{
"pre_open_utc_time": 144397000 (Mon Feb 17 22:30:00
2025),
"open_utc_time": 146197000 (Mon Feb 17 23:00:00 2025),
"close_utc_time": 201997000 (Tue Feb 18 14:30:00 2025),
"post_close_utc_time": 201997000 (Tue Feb 18 14:30:00
2025),
"trade_date": 149797000 (Tue Feb 18 00:00:00 2025),
"session_name": "Globex Night"
}
]
}
}
]
}
TradingDayTimeRangeRequest allows to get trading days with open/close times as well as holidays.
Get 3 trading sessions since LogonResult.base_time (from_utc_time is 0) for EP (session_info_id obtained from ContractMetadata from symbol resolution).
Client Message:
{
"information_requests": [
{
"id": 8,
"trading_day_timerange_request": {
"session_info_id": 206,
"from_utc_time": 0,
"count": 3
}
}
]
}
Server Response:
(with additionally converted times)
{
"information_reports": [
{
"id":
8,
"status_code":
0,
"trading_day_timerange_report": {
"trading_day_time_ranges": [
{
"trade_date": 149797000 (Tue Feb 18 00:00:00 2025),
"trading_day_pre_open_utc_time": 57997000 (Sun Feb 16 22:30:00
2025),
"trading_day_post_close_utc_time": 230737000 (Tue Feb 18 22:29:00
2025),
"open_primary_utc_time": 201997000 (Tue Feb 18 14:30:00
2025),
"close_primary_utc_time": 226297000 (Tue Feb 18 21:15:00
2025),
"trading_day_open_utc_time": 59797000 (Sun Feb 16 23:00:00
2025),
"trading_day_close_utc_time": 228997000 (Tue Feb 18 22:00:00
2025)
},
{
"trade_date": 236197000 (Wed Feb 19 00:00:00 2025),
"trading_day_pre_open_utc_time": 230797000 (Tue Feb 18 22:30:00
2025),
"trading_day_post_close_utc_time": 317137000 (Wed Feb 19 22:29:00
2025),
"open_primary_utc_time": 288397000 (Wed Feb 19 14:30:00
2025),
"close_primary_utc_time": 312697000 (Wed Feb 19 21:15:00
2025),
"trading_day_open_utc_time": 232597000 (Tue Feb 18 23:00:00
2025),
"trading_day_close_utc_time": 315397000 (Wed Feb 19 22:00:00
2025)
},
{
"trade_date": 322597000 (Thu Feb 20 00:00:00 2025),
"trading_day_pre_open_utc_time": 317197000 (Wed Feb 19 22:30:00
2025),
"trading_day_post_close_utc_time": 403537000 (Thu Feb 20 22:29:00
2025),
"open_primary_utc_time": 374797000 (Thu Feb 20 14:30:00
2025),
"close_primary_utc_time": 399097000 (Thu Feb 20 21:15:00
2025),
"trading_day_open_utc_time": 318997000 (Wed Feb 19 23:00:00
2025),
"trading_day_close_utc_time": 401797000 (Thu Feb 20 22:00:00
2025)
}
]
}
}
]
}
SessionInformationRequest provides session information in schedule format. However, extracting sessions for a specific date can be complex due to factors such as daily/session holidays and sessions without an associated trading day. Before using this request, check whether TradingDayTimeRangeRequest or SessionTimeRangeRequest meets your needs.
Get session schedule which was actual at LogonResult.base_time (from_utc_time and to_utc_time are 0) for EP (session_info_id obtained from ContractMetadata from symbol resolution).
Client Message:
{
"information_requests": [
{
"id": 0,
"session_information_request": {
"session_info_id": 206,
"from_utc_time": 0,
"to_utc_time": 0
}
}
]
}
Server Response:
(with additionally converted times, *_offset fields are offsets since day midnight)
Obtained single segment (Jan 21 2025 - Feb 17 2025) with 3 sessions (“Globex”, “Globex Day”, “Globex Night”) and 5 trading days (Monday-Friday) and no holidays.
{
"information_reports": [
{
"id":
7,
"is_report_complete":
true,
"status_code":
0,
"session_information_report": {
"session_info_id": 206,
"session_segments": [
{
"session_segment_id": 0,
"from_utc_time": -2269403000 (Tue Jan 21 00:00:00 2025),
"to_utc_time": 63397000 (Mon Feb 17 00:00:00 2025),
"session_schedules": [
{
"name": "Globex Night",
"session_days": [
{
"days_of_week": [4, 1, 3, 5, 2],
"pre_open_offset": -5400000 (-1 day, 22:30:00),
"open_offset":
-3600000 (-1 day, 23:00:00),
"close_offset": 52200000 (14:30:00),
"post_close_offset": 52200000 (14:30:00)
}
],
"is_primary": false
},
{
"name": "Globex Day",
"session_days": [
{
"days_of_week": [2, 5, 4, 3, 1],
"pre_open_offset": 52200000 (14:30:00),
"open_offset": 52200000 (14:30:00),
"close_offset": 76500000 (21:15:00),
"post_close_offset": 76500000 (21:15:00)
}
],
"is_primary": true
},
{
"name": "Globex",
"session_days": [
{
"days_of_week": [1, 4, 3, 2, 5],
"pre_open_offset": 76500000 (21:15:00),
"open_offset": 76500000 (21:15:00),
"close_offset": 79200000 (22:00:00),
"post_close_offset": 80940000 (22:29:00)
}
],
"is_primary": false
}
],
"trading_days": [
{
"days_of_week": [1, 2, 3, 4, 5],
"start_offset": -5400000 (-1 day, 22:30:00)
}
]
}
]
}
}
]
}