Matches

A single match

One match by id, with the same fields as a list row minus the denormalised names — a detail row carries bare `team_a_id`/`team_b_id`/`tournament_id`, so resolve those separately or read them off the list route instead. The `data_available` flags tell you which sub-resources (`maps`, `stats`, `map_stats`, `vetoes`, `rounds`, `depth`, `lineups`, `odds`) actually exist for this match, so you can skip requests that would return an empty list. Pass `include=` to embed related resources or the sub-resources themselves in this one response.

GET
/v1/{game}/matches/{id}

One match by id, with the same fields as a list row minus the denormalised names — a detail row carries bare team_a_id/team_b_id/tournament_id, so resolve those separately or read them off the list route instead. The data_available flags tell you which sub-resources (maps, stats, map_stats, vetoes, rounds, depth, lineups, odds) actually exist for this match, so you can skip requests that would return an empty list. Pass include= to embed related resources or the sub-resources themselves in this one response.

Authorization

AuthorizationBearer <token>

Primary auth (live). Authorization: Bearer <api-key> — the header takes precedence over the query fallback. The raw key is hashed (SHA-256, hex) and looked up in api.keys.key_hash; the raw value is never stored.

In: header

Path Parameters

game*string

Game slug. cs2 is the only populated title today; an un-onboarded game 404s cleanly.

id*string

Resource identifier — either a UUID or the resource's human-readable slug, scoped to {game}. /v1/cs2/teams/natus-vincere and /v1/cs2/teams/019f23d1-fb5c-7987-b522-47c3a5e72111 address the same row, so you can go straight from a slug you already have without first looking up its id.

Slugs work on teams, players and tournaments. Matches have no slug, so a match id must be a UUID. Either way, an identifier that resolves to nothing returns 404 not_found.

Query Parameters

include?string

Comma-separated related resources to embed inline: teams (adds team_a/team_b), tournament, and odds (the latest derived line per outcome). include=teams,tournament,odds turns the four requests a match view needs into one. Unknown names are ignored rather than rejected, so adding an expansion later never breaks an existing client. Omit it and the response is exactly as before — every embedded field is absent, not null.

The match's own data can be embedded the same way: maps, stats, vetoes, rounds, depth, lineups, streams and players, each identical to what the matching /matches/{id}/... route returns — except players, which has no standalone route: it is the union of the players named by this match's lineups and stats rows, resolved to full rows, so a lineup or a scoreboard can be rendered without one /players/{id} request per player. include=maps,stats,vetoes,rounds,depth,lineups,players replaces six follow-up requests with none. A requested one is always present (empty when the match has none); to do this for many matches at once use /v1/{game}/matches/bulk.

Only the detail route offers this: a match row from /v1/{game}/matches already carries team_a_name, team_b_name, team_a_short, team_b_short and tournament_name denormalised, whereas the detail route returns bare ids.

Response Body

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/v1/cs2/matches/019f2858-e253-7f3d-bdff-bc7738bd1036"
{  "data": {    "id": "01a0a3e2-96a5-7a9f-8af2-fae0f1a7d678",    "game_id": "019f23d1-fb5b-7d24-935d-e4d68f6f565a",    "tournament_id": "01a09164-2d84-7c6e-9d80-a42c8c70ce12",    "team_a_id": "019f2858-e255-78e4-9e7c-32f307dfac91",    "team_b_id": "01a0a3e2-96a0-7bf7-986c-6a68e151de5c",    "format": "bo3",    "status": "completed",    "stage": "Circuit X Curitiba 3 Group D",    "scheduled_at": "2026-09-18T02:25:00Z",    "started_at": "2026-09-17T19:56:50.826573Z",    "ended_at": "2026-09-18T03:44:28Z",    "score_a": 2,    "score_b": 0,    "winner_team_id": "019f2858-e255-78e4-9e7c-32f307dfac91",    "result_type": "played",    "live_state": null,    "created_at": "2026-09-15T07:05:50.158384Z",    "updated_at": "2026-09-18T10:59:10.806164Z",    "changed_at": "2026-09-18T03:49:12.004518Z",    "data_available": {      "maps": true,      "stats": true,      "map_stats": true,      "vetoes": true,      "rounds": true,      "depth": true,      "lineups": true,      "odds": false    }  }}
{  "error": {    "code": "not_found",    "message": "not found",    "request_id": "019f3d18-c15f-7319-81a7-343e8a80a578"  }}
{  "error": {    "code": "not_found",    "message": "not found",    "request_id": "019f3d18-c15f-7319-81a7-343e8a80a578"  }}

{  "error": {    "code": "rate_limited",    "message": "rate limit exceeded",    "request_id": "019f3d18-c15f-7319-81a7-343e8a80a578"  }}

Per-player CS2 depth breakdowns for one match GET

The five CS2 depth breakdowns for one match, grouped into a single object: per-player `weapons`, `grenades`, `hitgroups` (body hit-group distribution), `duels` (the killer→victim kills matrix) and `flashes` (the flasher→flashed blind matrix). These are per-MATCH aggregates (not per map). Each group is a flat array whose elements carry their own `player_id` (and, for duels/flashes, the ordered pair of player ids), so a client groups by player itself. A match with no depth on record (older or lower-tier matches — roughly one in six lack it) returns every group as an empty array (never null); an unknown match id does the same. Single-resource envelope: `{"data": {weapons, grenades, hitgroups, duels, flashes}}`.

Pre-match roster snapshots for a match GET

Each team's listed roster as it stood in the 48 hours before the match, oldest snapshot first within each team. **This is a roster snapshot, not a confirmed starting five.** Substitutes are listed too, so `player_ids` usually holds 6 or 7 ids and can hold anywhere from 1 to 11 — never assume a length of 5. The five who actually played are the player rows on `/stats`; compare the two to see who was benched or who stood in. A new row is written only when a team's roster differs from its previous snapshot, so most teams have exactly one row per match, and a second row means the roster changed in the run-up. An old `captured_at` is therefore not staleness. Coverage starts on 2026-07-09 and reaches roughly 6 in 10 matches since then; every earlier match returns an empty list. `data_available.lineups` and `?has=lineups` tell you which. An unknown match id also returns an empty list.