Before
API-Football integrations commonly use provider-specific API-key headers (or RapidAPI headers when consumed through RapidAPI). Keep that detail isolated in your existing client wrapper.
Migration guide
Move from API-Football.
A technical mapping for developers who already have an API-Football integration. This guide describes equivalence and gaps; it does not claim drop-in compatibility.
Migration rule
Do not carry provider IDs across. Resolve SportsFoundry sport, competition, edition, team and event IDs from SportsFoundry itself and persist that mapping in your application where necessary.
Endpoint map
Map the job, not the URL.
API-Football and SportsFoundry use different resource models. The closest customer-facing SportsFoundry operations are shown below.
| Developer job | API-Football pattern | SportsFoundry | Equivalence |
|---|---|---|---|
| List competitions/leagues | GET /leagues | GET /api/v1/competitions then /api/v1/editions | Model differs |
| Teams in a season | GET /teams?league=…&season=… | GET /api/v1/teams?competitionEditionId=… | Equivalent job |
| Fixtures / results | GET /fixtures | GET /api/v1/events | Status/schema mapping |
| One fixture | GET /fixtures?id=… | GET /api/v1/events/{eventId} | Equivalent job |
| League table | GET /standings | GET /api/v1/editions/{editionId}/standings | Equivalent job |
| Current squad | team/player endpoints | GET /api/v1/teams/{teamId}/squad | Model differs |
| Player detail | player endpoints | GET /api/v1/players/{playerId} | Depth differs |
| Odds, predictions, line-ups and provider-specific statistics | dedicated API-Football endpoints | No general API-v1 equivalent currently advertised | Not equivalent |
Authentication
Move authentication into one client boundary.
After
SportsFoundry customer requests use a workspace-owned X-API-Key.
curl -s https://sportsfoundry.app/api/v1/events \
-H "X-API-Key: $SPORTSFOUNDRY_API_KEY"Semantic differences
Things to change deliberately.
Identifiers
IDs are not portable between providers. Re-resolve and store SportsFoundry identifiers.
Event status
Map your current fixture-state model to the SportsFoundry event statuses in the OpenAPI enum rather than comparing provider strings directly.
Pagination
/api/v1/events uses a bounded limit and opaque cursor. Do not translate page numbers into guessed cursors.
Limits & failures
Handle 401, 403 and 429 explicitly and retain X-Correlation-Id when support is required.
Checklist
Cut over with evidence.
1
Inventory the calls you actually use
Do not migrate unused endpoints or fields.
2
Resolve SportsFoundry IDs
Map competitions, editions, teams and events before comparing payloads.
3
Run both integrations against the same use cases
Compare the fields your product depends on; expect model differences rather than byte-for-byte equality.
4
Verify unsupported dependencies
Do not cut over if your product requires a capability SportsFoundry does not currently advertise.
5
Switch and monitor
Keep correlation IDs and watch usage/limits in Account during the first production window.