The dual-ID model
Every Football V2 competition is identified by two numeric IDs that look interchangeable but are not.uniqueTournament.id is the canonical, season-independent identifier for a league or competition. tournament.id is a per-season, per-group variant that changes every year and is only meaningful when paired with a seasonId.
Mixing them up is the single most common cause of broken integrations — IDs that worked last season silently stop resolving when the new season rolls over.
Side-by-side
Worked example
A trimmed/api/event/{id} response shows both fields side by side:
tournament.uniqueTournament.id = 17→ store this. It will still be17in 2030.tournament.id = 1→ never store this. Next season it’s a different number.season.id = 76986→ discover dynamically via/api/tournaments/17/seasonswhenever you need season-scoped data.
Confirmed canonical IDs (top competitions)
When to use which
UseuniqueTournament.id when:
- Storing a competition reference in your database
- Filtering matches, fixtures, or teams by competition
- Loading a league logo via
/images/tournaments/{id} - Querying competition-level metadata that doesn’t depend on the current season
tournament.id (paired with seasonId) only when:
- Calling season-scoped endpoints such as:
/api/tournament/{tournamentId}/season/{seasonId}/standings/api/tournament/{tournamentId}/season/{seasonId}/top-players/.../api/tournament/{tournamentId}/season/{seasonId}/cuptrees
tournament.id and seasonId dynamically every time — don’t cache them past a single season.
Resolution flow
tournamentId for the season-scoped call comes from the same seasons response — never hardcode it.
Anti-pattern
Related
- Tournament endpoints reference
- Search endpoint — discover
uniqueTournament.idby name - One-Time ID Migration Guide
- Image endpoint troubleshooting