Overview
API-Football and SportMonks are two of the most popular football data APIs, but they take different design philosophies. API-Football bundles many sports under one umbrella with simple per-sport endpoints, while SportMonks is football-first with deeper enrichment, nested includes, and a more flexible filtering system. Migrating between them is rarely a drop-in replacement.
Teams typically move to SportMonks for richer in-play data, custom plan flexibility, and superior league coverage, or away from API-Football when they hit the rate limits of the RapidAPI-hosted version. This guide maps every common endpoint, highlights the data-shape differences that break parsers, and gives you a checklist you can run end-to-end before cutting over traffic.
Before you start: Use the SportMonks profile to confirm coverage for every league your app currently serves. SportMonks splits leagues across plan tiers, and a league that was included on API-Football may require a higher SportMonks plan.
Why Migrate?
Migration is a significant investment, so the trade-offs need to be worth it. The most common reasons teams switch from API-Football to SportMonks are:
- Deeper football data — SportMonks offers player-level XG, expected goals against, lineup projections, and referee statistics that API-Football does not expose.
- Flexible nested includes — a single request can return fixtures, league, season, score, events, and lineups, reducing request count and orchestration code.
- Custom plan negotiation — SportMonks offers tailored plans for high-volume customers, while API-Football is priced per fixed tier.
- More consistent naming — SportMonks uses stable team and league IDs, avoiding the alias drift that API-Football occasionally introduces.
On the other hand, API-Football wins on breadth (it covers basketball, baseball, hockey, and more in one API) and on a generous free tier. If your product is multi-sport, a full migration may not be the right call — consider keeping API-Football for non-football sports.
Endpoint Mapping
SportMonks uses a flat resource model under /v3/football, while API-Football groups everything under /v3 with sport-specific paths. The table below maps the most common endpoints:
| API-Football Endpoint | SportMonks Equivalent | Notes |
|---|---|---|
| /fixtures?live=all | /v3/football/livescores | Live in-play fixtures only |
| /fixtures?date=2026-08-20 | /v3/football/fixtures/date/2026-08-20 | Path parameter vs query |
| /fixtures?id=12345 | /v3/football/fixtures/12345 | ID is a path segment |
| /standings?league=39&season=2025 | /v3/football/standings?filters=fixtureLeagues:39;seasonID:2025 | Uses filter syntax |
| /teams?id=49 | /v3/football/teams/49 | Direct mapping |
| /players?id=276 | /v3/football/players/276 | Player data may need higher plan |
| /fixtures/events?fixture=12345 | /v3/football/fixtures/12345?include=events | Use include parameter |
| /fixtures/lineups?fixture=12345 | /v3/football/lineups/fixture/12345 | Dedicated lineups endpoint |
| /odds?fixture=12345 | /v3/football/odds?fixture=12345 | Odds require an add-on |
| /leagues?id=39 | /v3/football/leagues/39 | Direct mapping |
Data Format Differences
The response shapes differ substantially. API-Football wraps every response in { get, parameters, errors, results, paging, response }, while SportMonks returns { data, ... } with meta in the response headers. The biggest parser-breaking changes are:
- Score structure — API-Football nests scores under
fixture.goals; SportMonks splits them intoscores.homeandscores.awaywith separate full-time and half-time objects. - Status objects — API-Football uses
fixture.status.short("1H", "FT", "NS"); SportMonks usesstate.namewith longer labels. - Team IDs — the same physical team will have a different ID in each provider. You must maintain an ID mapping table during migration.
- Includes vs separate calls — data that required three API-Football calls (fixture, events, lineups) can be fetched in one SportMonks call using
?include=events;lineups.
Before & After: API Calls
Fetching a fixture with lineups (API-Football)
On API-Football you fetch the fixture and the lineups in two separate requests and join them client-side:
// API-Football — two requests, manual join
const API_KEY = process.env.APIFOOTBALL_KEY;
const base = "https://v3.football.api-sports.io";
// 1. Fetch the fixture
const fixtureRes = await fetch(`${base}/fixtures?id=215662`, {
headers: { "x-apisports-key": API_KEY },
});
const fixtureJson = await fixtureRes.json();
const fixture = fixtureJson.response[0];
// 2. Fetch the lineups separately
const lineupRes = await fetch(`${base}/fixtures/lineups?fixture=215662`, {
headers: { "x-apisports-key": API_KEY },
});
const lineupJson = await lineupRes.json();
const lineups = lineupJson.response;
// 3. Merge by fixture id
const merged = { ...fixture, lineups };Fetching a fixture with lineups (SportMonks)
On SportMonks the same data is one request thanks to the include parameter, and the response is flatter:
// SportMonks — one request, nested includes
const API_KEY = process.env.SPORTMONKS_KEY;
const base = "https://api.sportmonks.com/v3/football";
// Single request returns fixture + events + lineups
const res = await fetch(
`${base}/fixtures/215662?include=events;lineups`,
{ headers: { Authorization: `Bearer ${API_KEY}` } }
);
const { data } = await res.json();
// data already contains events and lineups inline
const merged = data;Watch out: SportMonks uses a Bearer token in the Authorization header, while API-Football expects an x-apisports-key header. Update your auth wrapper before sending any traffic.
Pricing Comparison
Pricing models are not directly comparable because SportMonks gates leagues behind plan tiers while API-Football offers all leagues on every paid plan. Estimate your cost for the specific leagues you need:
| Tier | API-Football | SportMonks | Best For |
|---|---|---|---|
| Free | 100 req/day, all sports | No free tier | Prototyping (API-Football) |
| Starter | $24.99/mo, 50k req | $39/mo, 2 leagues | Single-league apps |
| Pro | $49.99/mo, 200k req | $79/mo, 5 leagues | Multi-league apps |
| Enterprise | $149.99/mo, 1M req | Custom pricing | High-volume platforms |
Migration Checklist
Inventory every API-Football endpoint your app calls and confirm the SportMonks equivalent exists.
Map API-Football team and league IDs to SportMonks IDs and store the mapping in a lookup table.
Update your auth layer to send the SportMonks Bearer token instead of the x-apisports-key header.
Rewrite your response parsers to read data.data instead of response[].
Replace multi-call fixtures with single include-based requests to cut request volume.
Verify that every league you serve is covered by your target SportMonks plan tier.
Reconcile score and status field names (scores.home/away vs fixture.goals, state.name vs status.short).
Run the parallel-traffic test phase (see below) for at least one full matchday.
Best Practices
Maintain a dual-write ID mapping table
During migration, store both the API-Football and SportMonks IDs for every team and league. This lets you fall back to the old provider if SportMonks has an outage, and it makes rollback trivial.
Embrace includes to cut request count
SportMonks charges per request, not per nested include. Where API-Football forced you into three calls for fixture + events + lineups, use a single include-based request. This often reduces request volume by 60% and lowers your bill.
Run parallel traffic before cutting over
Never switch production traffic abruptly. Run both providers in parallel, diff the responses, and only cut over when the diff rate is below your tolerance threshold for a full matchday.
Check league availability before committing to a plan
SportMonks gates leagues behind plan tiers. A league included on API-Football's cheapest paid plan may require SportMonks' Pro or Enterprise tier. Confirm coverage before you commit to a contract.
Related Guides
Migrating from RapidAPI to Direct API Access
11 min readMigrating from Sportradar to SportsDataIO
13 min readCaching Strategies for Sports API Data
12 min readCompare API-Football and SportMonks side by side
See scores, pricing, and feature coverage for both providers in one place.