Versioning & game namespacing

Every endpoint follows one path convention:

/v1/{game}/{resource}

• v1 — the major API version. Breaking changes ship under a new version prefix; v1 stays stable and additive.
• {game} — the game namespace. Today the only populated value is cs2 (Counter-Strike 2). The API is game-agnostic by construction, so a future title slots in as its own namespace without changing any existing cs2 path.
• {resource} — the collection, e.g. matches, odds, teams, tournaments, players.

Examples

GET /v1/cs2/matches?status=live
GET /v1/cs2/matches/{id}
GET /v1/cs2/odds?match={matchId}
GET /v1/cs2/teams
GET /v1/cs2/teams/{id}
GET /v1/cs2/tournaments
GET /v1/cs2/players

Unknown games

A request for a game that isn't onboarded yet returns a clean 404 Not Found, not a server error:

curl "https://api.esportsodds.gg/v1/valorant/matches?apiKey=YOUR_API_KEY"
# 404 { "error": "unknown game" }

That means you can write a client against /v1/{game}/... today and point it at a new game the day it's added — the shape won't change.

Adding a second game later

When a new title is onboarded, it appears as a new {game} slug with the same resources under it (/v1/{newgame}/matches, /v1/{newgame}/odds, and so on). Existing cs2 integrations are untouched. Watch the changelog for new namespaces.