Skip to main content
This page documents the strongly-typed fields on the instrument that should be used to identify a sports market. Do not parse the instrument symbol or slug — symbol formats are not part of the public contract and may change. Always identify markets using the fields below.

​
Section 1: Common Identifying Fields

The following fields appear on every sports instrument. Together they uniquely describe the sport, league, event, period, market type, and handicap of a contract.

​
Field Reference

​
outcome_type Enum

The market structure of a sports instrument.

​
market_sport_type Enum

The fully-qualified market type, including sport, participant scope, and game period. This field is populated on every sports instrument — full-game spreads, totals, and outright winners included — so you can treat it as the single source of truth for any market. You no longer need to check outcome_type to map a market; market_sport_type alone is sufficient. Some values are registered before their first listing; treat every value in this table as one that can appear on an instrument. Esports map markets (esports_map_*) apply to round-based titles such as Counter-Strike 2 and Valorant. Esports game markets (esports_game_*) apply to titles played as a series of games such as League of Legends and Dota 2. Series markets (esports_series_*) cover the whole best-of series.
The market_sport_type enum is the source of truth for sport, period, and prop variants, and is now guaranteed to be present on every instrument. When in doubt about which value applies to a market you’re seeing, use this field rather than parsing the symbol.

​
Generic Values

Four generic values are also registered. Each has the same market structure as the matching outcome_type value. They appear on instruments that carry no sport-specific value: instruments created before the sport-specific values existed, hand-listed markets, and sports that do not yet have their own winner, spread, or total type. Treat them as valid market_sport_type values and map them by structure: moneyline is a 2-way winner, spreads is a handicap, totals is an over/under, and drawable_outcome is a 3-way winner that admits a draw. These values carry no sport or period, so read the sport from event_subcategory. On Retail data, sportsMarketType shows the outcome_type value (for example futures) when the instrument carries no market_sport_type at all.

​
Football Market Metadata

Use structured metadata rather than parsing an NFL instrument ID. Markets for the same game share an event_id containing the canonical game slug without a contract prefix. event_product_id is the exchange’s event-level product grouping and is not a substitute for event_id; product_id groups the strikes or outcomes belonging to one market product. For NFL game props, use this tuple as the canonical lookup and deduplication key:
Participant IDs can be empty for game-wide totals. For player props, also use external_participant_id to resolve and validate the player.

​
Football Metadata Profiles

In addition to event_id, event_external_id_sportradar, market_sport_type, and product_id, use the fields required by the market’s profile: Race-to-points markets (football_game_race_to_points) are mutually exclusive team-outcome products, like the first-score markets. Each points target (7, 14, 21, 28, 35) is one product with three instruments: away team, home team, and Neither Team. outcome_strike carries the points target on all three legs. long_participant_id names the team on the team legs and is absent on the Neither Team leg; short_participant_id is not set. Live next-touchdown and next-field-goal markets (football_next_team_touchdown, football_next_team_field_goal) re-list during the game. Each touchdown or field-goal number is one product with three instruments: away team, home team, and No TD or No FG. The first instance lists at kickoff, a new instance lists after each confirmed touchdown or made field goal, and none lists in overtime. Successive instances share market_sport_type, event_id, and participant IDs, so the canonical deduplication key above does not separate them. Use product_id (<game slug>-next-team-td-<n>, <game slug>-next-team-fg-<n>) or the touchdown_number / field_goal_number metadata field instead. On these legs outcome_strike holds the team abbreviation or no-td / no-fg, not a number.

​
Section 2: Identifying Markets

Use this table as a recipe book for identifying a specific market type from instrument metadata. Match on market_sport_type alone — it fully identifies any market (structure and period), so you no longer need to check outcome_type.

​
Worked Example: Cleveland/Detroit Over 4.5 Total

A full-game total on the May 21 Cleveland Guardians vs Detroit Tigers MLB game:
To safely interpret this contract:
  1. market_sport_type = "baseball_team_full_game_total" → full-game total. (outcome_type is also present but you don’t need it.)
  2. event_subcategory = "BASEBALL" → MLB game.
  3. outcome_strike = "4.5" → over/under line is 4.5 combined runs.
  4. The contract resolves “Over” if the combined score is 4.5 or more, otherwise “Under”.

​
Worked Example: Cleveland +3.5 Spread

A full-game run-line spread on the May 20 Cleveland Guardians vs Detroit Tigers MLB game:
To safely interpret this contract:
  1. market_sport_type = "baseball_team_full_game_spread" → full-game spread. (outcome_type is also present but you don’t need it.)
  2. long_participant_id = "mlb-cle" → the contract pays out on Cleveland.
  3. outcome_strike = "3.5" → handicap magnitude is 3.5 runs.
  4. The contract resolves to Cleveland if Cleveland wins, or loses by fewer than 3.5 runs.

​
Best Practices

  • Never parse the symbol or slug to determine market type, period, or handicap. Symbol formats are not part of the public contract.
  • Map on market_sport_type alone. It is guaranteed on every instrument — full-game, sub-period, and prop alike — and fully identifies the market. outcome_type is still present on the instrument, but do not rely on it for mapping (it is subject to change); the sole exception is futures, which carry no market_sport_type and are identified by outcome_type = "futures".
  • Treat outcome_strike as a string in client code and convert to your numeric type. The value is unsigned — the spread direction is determined by long_participant_id.
  • Cache and version your enum mappings. New market_sport_type values are announced in the changelog and rolled out in preprod before production. Subscribe to the RSS feed to be notified before new enums appear in production. An instrument can carry a value that is not yet in this inventory: treat an unknown value as a prop, fall back to outcome_type for its structure, and watch the changelog for the new value.
  • Subscribe to instrument updates via the streaming APIs to catch new instruments as they are listed.