Skip to main content

Why migrate IDs

Entity IDs in SportsAPI Pro (players, teams, tournaments, countries) are not portable from other providers. If you previously used a different sports data API and stored their IDs, those IDs will not resolve against our endpoints — image and data calls will return 404. The fix is a one-time migration: walk your existing entity names through /search, collect the canonical SportsAPI Pro IDs, and store them in a mapping table you control.
This guide uses football examples, but the same flow works for every sport — just call the corresponding sport subdomain (e.g. v2.basketball.sportsapipro.com).

Step 1 — Export your existing names

Pull the names you currently store. CSV is fine; so is a SQL export.
You should end up with rows like:

Step 2 — Call /search for each name

For every row, call:
Respect the rate limit. Throttle to roughly 5 requests/second with a small jitter, and debounce duplicate names client-side. A 10k-row migration finishes in well under an hour at 5 rps.

Step 3 — Pick the right result type

The response contains separate arrays — read the one matching the entity type:
For tournaments, always store competitions[].id (the canonical league ID) — never the per-season tournament.id returned from match endpoints. See Canonical IDs for the full explanation.

Step 4 — Disambiguate common names

A query like Barcelona returns multiple competitors:
Two reliable disambiguation strategies:
  1. Rank by popularityRank descending — the highest value is almost always the household-name entity.
  2. Match on countryId — if your legacy row carries country, filter to it before picking.
Flag rows where the top result is more than 10× ahead of #2 as auto-confident; everything else goes into a manual review queue.

Step 5 — Persist to a mapping table

Step 6 — Switch your app over and verify

Update your read paths to JOIN through entity_id_map. Then verify with the image endpoint — it’s the cheapest sanity check:
A 404 here means the canonical ID is wrong — re-run search for that row.

Starter script — Node.js

Starter script — Python


Common pitfalls

Don’t store tournament.id from match endpoints — it changes every season. Store uniqueTournament.id (returned as competitions[].id in /search). See Canonical IDs.
  • Don’t trust the first result blindly for short or generic names — always sort by popularityRank or filter by countryId.
  • Don’t migrate via the image endpoint. Image 404 confirms a bad ID but won’t tell you the right one. /search is the discovery tool.
  • Cache /search responses during migration — duplicate names are common.
Last modified on June 29, 2026