CS2 API reference.
Props, history, and IDs that survive roster churn.

Many teams hit the same wall for different reasons. The first problem is source fragmentation — the same CS2 event can appear in a DFS app, a sportsbook, HLTV, and a tracker, but none share a key you can trust downstream. The second is roster churn — team tags and handles change often enough that free-text joins degrade. The third is retention gaps— yesterday's PrizePicks line is gone from the app, so scrapers that worked last month fail when you need a backtest.

A lot of integrations fail because they treat a match like one row. In practice the record is a series container with two teams, a start time, and one or more map children. Player props hang off that series with map scope (map 1, maps 1–2, etc.) — which is why collapsing everything into a single object makes grading and backtests drift.

A normalized provider should expose endpoint families that match how developers work. Live boards start with props. Schedule and live products need matches. Backtests need gamelogs and history. The shapes below are the production KashRock paths under /v6/esports/cs2/.

Each response should stay boring for client code: the same envelope, UTC timestamps, and explicit status — not a pile of boolean flags that hide delayed or forfeited series.

Identifiers decide whether historical joins stay reliable or drift apart. Steam persona names change, team pages get reworked after roster moves, and book labels often stop matching the underlying entity. KashRock mints kr_prop_*, kr_pl_*, and canonical event/team IDs so the join survives the rename.

• —propId — stable contract across books for the same player/market/event
• —canonical_player_id — one person through handle changes
• —canonical_event_id / matchup_key — series join when book event IDs diverge
• —stat_type — sport-prefixed keys like CS2_KILLS_MAPS_1_2

Practical rule: use display names only at the edge, after the join has been resolved through canonical IDs.

A useful payload is not a raw book dump. It's a normalized object with the fields you need to shop lines, build pick'ems, and grade later — pulled live from production, not invented for the docs.

{
  "source": "kashrock",
  "sport": "cs2",
  "props": [
    {
      "propId": "kr_prop_14e79be2b6bc",
      "player_name": "n1ssim",
      "stat_type": "CS2_KILLS_MAPS_1_2",
      "line": 26.5,
      "odds": -137,
      "direction": "over",
      "team": "Legacy",
      "book_name": "PrizePicks",
      "event_time": "2026-09-12T06:00:00.000Z",
      "links": {
        "market": "https://app.prizepicks.com/?projections=14751913-o-26.5"
      }
    }
  ]
}

Choose your CS2 source by query shape: recent personal matches, audit-grade event records, or schema-normalized ingestion — instead of assuming one site covers every workflow.

Grading a prop is a join with sharper consequences. Bind the ticket to propId, book, line, and direction at placement, then resolve against finalized map stats.

• —Hit / miss — the canonical map record contained the stat and the line resolved.
• —Push — the stat landed exactly on the threshold.
• —Unmatched / void — the map or player could not be found; do not invent a grade.

Practical rule: don't grade from screenshots or partial text logs. Grade from the finalized map record, then store the raw evidence beside it.

• —Separate live board polls from archive backfills — they fail differently.
• —Cache completed records longer; keep live boards on a short TTL.
• —Stamp objects with fetched_at and verification status for audits.
• —Prefer path-style GET /v6/esports/cs2/props over slow query-string aliases.

Keep this open beside your IDE: propId stays stable across books, stat_type is sport-prefixed and map-scoped, timestamps are UTC, and Sandbox lets you prove the schema before you pay. Full route index: docs API reference.