Skip to main content
GET
Catalog of CS2 market types with templates and translations

What it returns

The full catalog of market types the engine can publish. Each entry has:
  • type — internal string id ("headshot_opening", "awp_kill", …)
  • code — stable integer code, used as id in the AMQP/XML feed and on every <odds_change> market element
  • name — human-readable English label (JSON). In the XML form this attribute instead carries the parametrized template with {placeholder} tokens (see below) — substitute specifier values into it at render time.
  • description — short English prose description
  • template / template_ru — the parametrized name with {placeholder} tokens (JSON only; the locale-path XML puts the template directly in name and has no template_ru)
  • name_ru — Russian display name / template (JSON only; the locale-path XML is single-locale — request the ru path to get Russian in name)
  • category — display grouping (Opening Kills, Multi-Kills, Bomb, Economy, …)
  • tier — pricing/risk tier (featured, contextual, …)
  • outcomes — the market’s declared outcomes, each { id, name, name_ru }. A live <odds_change> outcome is unnamed (<outcome id="1">); match it against this list to get its display name. Every CS2 market is a single-outcome proposition (id="1", “Yes”), but the form supports multiple outcomes — a market may declare several, each with a stable id and a per-locale name template (e.g. a football 1X2 declares {home_team} / Draw / {away_team}). Outcome ids are stable for the market’s life (BB 3.5/3.7).
  • specifiers — the specifier keys the market declares, each { name, type } where type is integer | variable_text | decimal. This is the market instance’s stable identity (BB 3.5) — the live specifiers string matches it exactly and never mutates over the instance’s life. Render {placeholder} tokens in name only for keys listed here. CS2 markets carry map / round, plus player or competitor for player/team-scoped markets. (The in-game map_name is not a specifier — it is nullable and would mutate the identity; read it from the fixture/summary per-map data.)
Codes are immutable. Pull this once at integration time, store the mapping locally, and look up by code for every incoming market. No need to re-poll. The UOF-compatible XML form (GET descriptions/:locale/markets, or Accept: application/xml) nests these as <market_descriptions><market><outcomes>…</outcomes><specifiers>…</specifiers></market>. It is single-locale: the response carries each display string once, in the path’s :locale, with no name_ru / template_ru siblings — request descriptions/en/markets for English and descriptions/ru/markets for Russian. The <market name> and <outcome name> attributes are display templates — substitute {placeholder} tokens (e.g. {round}, {player} for player-scoped markets, {competitor} for team-scoped economy markets) from the live market’s specifiers. Outcome names with no placeholders (CS2 “Yes”) render as-is. (description has no Russian source today, so it stays English even under ru.)

Required scope

  • Minimum: cs2:markets:read

Localization

?lang=en (default) or ?lang=ru. Both locales return the same code and category — only the display strings differ. The English name is always present; name_ru is included as a separate field when a Russian translation exists.

Example

Where this fits

The AMQP feed also inlines textEN / textRU on every market, so light integrations can read those directly. UOF-style clients should drive off this catalog instead: the live <odds_change> market carries only id + specifiers and an unnamed <outcome id="1">, so you name the outcome from the catalog’s outcomes list and render name placeholders only for the keys in specifiers. Such clients ignore textEN / textRU entirely and depend on the structured outcomes / specifiers. Use it when you want to:
  • Name live outcomes and render specifier placeholders without parsing textEN.
  • Build a custom market browser UI grouped by category.
  • Pre-build a name lookup keyed by code.
  • Filter what to expose to your end-users by tier.

Authorizations

X-API-Key
string
header
required

Tenant API key issued during onboarding

Headers

accept
string
default:application/json

Query Parameters

lang
string
default:en

Locale: en (default) or ru.

Response

Successful Response

Last modified on June 21, 2026