Migrating from sportsdata.io

Endpoint-by-endpoint guide for teams switching from sportsdata.io. Most renames are straightforward; a few schema differences are worth knowing about.

Key differences

Auth: Bearer token (vs. header-based subscription key)
One schema across sports — same response envelope for NBA, NFL, MLB, NHL, soccer
WebSocket included on every endpoint, not a separate add-on
Consistent meta object with request_id and tier

Endpoint map

sportsdata.io	sportapi
`/v3/nba/scores/json/GamesByDate/{date}`	`/v1/nba/schedule?date_from=…&date_to=…`
`/v3/nba/stats/json/PlayerSeasonStats/{season}`	`/v1/nba/players?season=…`
`/v3/nba/stats/json/BoxScore/{gameid}`	`/v1/nba/games/{id}/box-score`
`/v3/nfl/scores/json/Injuries`	`/v1/nfl/injuries`

Schema changes

Field names are snake_case (sportsdata.io is PascalCase)
Team identifiers are 3-letter abbreviations (LAL), not numeric IDs
Timestamps are ISO 8601 UTC with Z suffix; no ambiguous tz strings
Player IDs are stable slugs (lebron-james); we provide a migration table for old IDs

💡

We can provide a migrations/players.csv mapping sportsdata.io PlayerID → sportapi player slug as part of the trial — ask during the sales call.

Migration checklist

Issue a parallel sportapi key, dual-write your data layer behind a feature flag
Replace field references using the snake_case mapping
Update team-ID lookups to use abbreviations
Cut over reads to sportapi behind a per-customer flag
Switch any polling jobs to WebSocket subscriptions where they fit
Decommission the sportsdata.io key once 100% of traffic is migrated