How it works.

Quick answer: KashRock pulls esports props, odds, and stats from every book and provider it covers, maps every player, team, and match onto one canonical KashRock ID, and returns all of it in the same JSON schema — so your code reads one API instead of a different response shape per source.

Built for shipping, not parsing strings. One analytics schema across schedules, props, stats, and outcome verification.
QuickstartPricing

Standardized JSON

Consistent response shape regardless of the source provider or esports title. Your client code stays the same when a book or feed changes underneath. A CS2 kills prop and a Dota 2 kills prop come back with the same fields — propId, stat_type, line, odds — only the stat_typevalue changes. Add a ninth title tomorrow and your parsing logic doesn't fork.

Cross-source mapping

Canonical IDs across players, teams, and matches keep joins stable when nicknames or roster labels diverge across books and stats providers. We hit this directly: an upstream source corrected a match's team order after the fact — a typo fix, not a rename — and the ID we'd minted from the original label almost froze permanently, so the correction would never have reached callers who followed the fixed link. Match identity now tracks the match itself, not whichever label happened to arrive first, so an upstream correction doesn't break the ID downstream.

One props call

Example shape from GET /v7/cs2/props:

{
  "source": "kashrock",
  "sport": "cs2",
  "props": [
    {
      "propId": "kr_prop_…",
      "player_name": "fear",
      "stat_type": "CS2_KILLS_MAPS_1_2",
      "line": 25.5,
      "odds": -118,
      "direction": "over",
      "team": "Fnatic",
      "book_name": "PrizePicks"
    }
  ]
}

Same convention on a different endpoint — GET /v7/cs2/matches:

{
  "source": "kashrock",
  "kr_match_id": "kr_cs2_imperial-vs-bestia-2026-08-15",
  "slug": "imperial-vs-bestia-2026-08-15",
  "sport": "esports_cs2",
  "status": "not_started",
  "event_time": "2026-08-15T20:00:00Z"
}

If you need a normalized feed instead of another UI wrapper, the Esports API exposes live boards, schedules, and history on one schema — with the IDs and outcome patterns that keep backtests and grading honest. Start free on Sandbox, or see published pricing.

Esports APIQuickstart →Pricing →Features →Docs →

Frequently asked questions

How does KashRock work?

KashRock pulls esports props, odds, and stats from every book and provider it covers, maps every player, team, and match onto one canonical KashRock ID, and returns all of it in the same JSON schema — so your code reads one API instead of a different response shape per source.

Is KashRock free to use?

Yes. Sandbox is $0 with an instant key — 500 requests every UTC day across every sport (props, matches, players, live REST). Paid plans start at $29/mo.

What is a canonical ID, and why does it matter?

A canonical ID (kr_prop_…, kr_match_id, canonical_player_id, canonical_team_id) is the one identifier KashRock mints per player, team, or match, regardless of how a book or stats provider labels it. It's what lets a join stay stable when an upstream label changes underneath it.

Do I need different code for each esports title or book?

No. Every title and book returns the same field names — propId, stat_type, line, odds — so one parser handles CS2, Valorant, LoL, Dota 2, and the rest.

Where do I find schema details for a specific title?

See the CS2 API, Dota 2 API, and esports data API pages for title-specific fields, stat types, and coverage.

How fast is the live data?

Under 2 seconds on Builder and Pro over REST and WebSocket; Hobby reads a 5-second delay and Sandbox 30-60 seconds. The delay is a plan tier, not a different pipeline.