Market Descriptions
Static catalog of every CS2 market type — code, name, category, tier, translations
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 asidin the AMQP/XML feed and on every<odds_change>market elementname— 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 descriptiontemplate/template_ru— the parametrized name with{placeholder}tokens (JSON only; the locale-path XML puts the template directly innameand has notemplate_ru)name_ru— Russian display name / template (JSON only; the locale-path XML is single-locale — request therupath to get Russian inname)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 stableidand a per-localenametemplate (e.g. a football1X2declares{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 }wheretypeisinteger|variable_text|decimal. This is the market instance’s stable identity (BB 3.5) — the livespecifiersstring matches it exactly and never mutates over the instance’s life. Render{placeholder}tokens innameonly for keys listed here. CS2 markets carrymap/round, plusplayerorcompetitorfor player/team-scoped markets. (The in-gamemap_nameis not a specifier — it is nullable and would mutate the identity; read it from the fixture/summary per-map data.)
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 inlinestextEN / 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.
Last modified on June 21, 2026
Catalog of CS2 market types with templates and translations