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 return404.
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.Step 2 — Call /search for each name
For every row, call:
Step 3 — Pick the right result type
The response contains separate arrays — read the one matching the entity type:Step 4 — Disambiguate common names
A query likeBarcelona returns multiple competitors:
- Rank by
popularityRankdescending — the highest value is almost always the household-name entity. - Match on
countryId— if your legacy row carries country, filter to it before picking.
Step 5 — Persist to a mapping table
Step 6 — Switch your app over and verify
Update your read paths to JOIN throughentity_id_map. Then verify with the image endpoint — it’s the cheapest sanity check:
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 trust the first result blindly for short or generic names — always sort by
popularityRankor filter bycountryId. - Don’t migrate via the image endpoint. Image
404confirms a bad ID but won’t tell you the right one./searchis the discovery tool. - Cache
/searchresponses during migration — duplicate names are common.