Migration · 14 min read

Migrating from API-Football to SportMonks

A complete migration guide covering endpoint mapping, data format differences, pricing considerations, and a testing strategy for switching your football data layer to SportMonks.

Last updated: August 2026

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 EndpointSportMonks EquivalentNotes
/fixtures?live=all/v3/football/livescoresLive in-play fixtures only
/fixtures?date=2026-08-20/v3/football/fixtures/date/2026-08-20Path parameter vs query
/fixtures?id=12345/v3/football/fixtures/12345ID is a path segment
/standings?league=39&season=2025/v3/football/standings?filters=fixtureLeagues:39;seasonID:2025Uses filter syntax
/teams?id=49/v3/football/teams/49Direct mapping
/players?id=276/v3/football/players/276Player data may need higher plan
/fixtures/events?fixture=12345/v3/football/fixtures/12345?include=eventsUse include parameter
/fixtures/lineups?fixture=12345/v3/football/lineups/fixture/12345Dedicated lineups endpoint
/odds?fixture=12345/v3/football/odds?fixture=12345Odds require an add-on
/leagues?id=39/v3/football/leagues/39Direct 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 into scores.home and scores.away with separate full-time and half-time objects.
  • Status objects — API-Football uses fixture.status.short ("1H", "FT", "NS"); SportMonks uses state.name with 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:

TierAPI-FootballSportMonksBest For
Free100 req/day, all sportsNo free tierPrototyping (API-Football)
Starter$24.99/mo, 50k req$39/mo, 2 leaguesSingle-league apps
Pro$49.99/mo, 200k req$79/mo, 5 leaguesMulti-league apps
Enterprise$149.99/mo, 1M reqCustom pricingHigh-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

Compare API-Football and SportMonks side by side

See scores, pricing, and feature coverage for both providers in one place.