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.
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.

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:

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.
  • Subscribe to instrument updates via the streaming APIs to catch new instruments as they are listed.