Alternative football scores API grouped by competition

Data sources evolve. When a source introduces a newer version of a service, existing integrations still depend on the old one, and switching everyone at once would break products that work today. So FootballAPI.net publishes both: the main scores feed at its established path, and scores-new as a separately documented service. Neither is deprecated on this page, and neither is a premium tier of the other.

The newer service returns matches grouped by competition, and its JSON responses have been verified through the gateway. Like the main feed, it takes no parameters and has a cache time of about thirty seconds. Like every feed, its qualification is sample received: a response has come back, while final freshness, coverage and licensing checks are pending. That label does not make it experimental in the sense of unstable, but it does mean we are not certifying completeness or latency.

The point of this page is not to tell you which one to use. It is to help you choose deliberately, and to avoid a specific mistake: writing one mapping layer and pointing it at both.

Both services return the gateway's standard outer envelope with data and meta. Inside data, though, each carries its own source structure. The grouping by competition in scores-new is a real structural difference, and there may be others in naming, nesting and which attributes appear. We do not normalise either into a shared schema, because doing so would hide exactly the differences you need to see when choosing.

Treat the two as separate integrations. If your code base uses both, give each its own mapping module with its own tests built from saved responses. A shared function that tries to read either structure tends to grow conditional branches until nobody is sure which path a given match took.

Comparisons are only fair if both requests happen at the same moment. Fetch both services within a few seconds of each other during a busy match window, save both bodies, and compare them on the things your product depends on. Which competitions appear in each? For a sample of matches present in both, do the identifiers line up? Are match states expressed in a way your interface can use? How large is each response, and how long does your server take to process it?

Repeat the comparison on a quiet day and on a day with late kick-offs in several timezones. A service that suits a Saturday afternoon may behave differently at the edges. Keep the saved bodies; they become your regression tests later.

If your interface is organised by competition anyway, which most score centres are, a response that already groups matches that way can simplify the rendering code. You iterate over competitions and then over their matches, rather than collecting matches into groups yourself. That is a modest benefit, not a decisive one, but it does remove a class of bugs where a match is assigned to the wrong group because of an inconsistent attribute.

Grouping in the response does not decide the order of groups on your page. Order them for your audience, as you would with any score centre, and keep the source group label rather than inventing your own competition names.

Some teams start on the main scores feed and later decide that scores-new suits them better, or the reverse. A safe migration runs both in parallel for a period. Your poller fetches both, your old mapping continues to serve readers, and your new mapping writes to a shadow store that you compare automatically. When the shadow output has matched for long enough across different kinds of match day, switch the reader-facing pages over and keep the old poller running for a short while as a fallback.

During the parallel period your request count roughly doubles for the score feeds. Budget for that explicitly. Two services polled every thirty seconds across a full day is 5,760 requests, which is above the Starter daily inclusion of 5,000, so a Starter customer would either poll less often or accept a small number of extra requests at EUR 0.002 each.

If you consume both scores services, write a small adapter for each that converts responses into your own internal match model. Your pages then render one model regardless of source. Keep the adapters separate and tested against saved samples, because the two services are documented separately and their structures should not be assumed to match.

Record in your internal model which service each match came from, so you can trace questions back to the right feed.

Save responses from this service separately from the main scores service and test its adapter on its own. Do not reuse fixtures from the other service in these tests.

Errors use the gateway's structured JSON body with a code, a message and a requestId. Handle a 429 by waiting for the Retry-After period, treat 502 and 504 as temporary, and keep showing your stored scores with their refresh time during an outage.

Scores-new is league filtered in the same way as the main feed. Starter responses at EUR 29 a month contain only your five saved leagues. Growth at EUR 99 and Pro at EUR 249 receive the available package competitions, with daily inclusions of 25,000 and 250,000 successful requests respectively. Whether a competition appears on a given day depends on the source on every plan.

There is no separate price for using both score services. Each successful request counts once towards the daily inclusion, whichever service answers it. Failed and denied requests are not billed, and the 100 requests per second account safety ceiling applies across all feeds together. There is no free trial and no VAT is currently charged.

Neither score service is a stream. Both are REST endpoints you poll, and each response is a snapshot. Neither contains positional or ball-tracking data, and subscribing to a plan does not activate any streaming or tracking product. Neither carries prices or predictions. If a product idea needs any of those, raise it with support before building on a score feed and hoping the gap closes later.

And neither replaces a fixture list. A score feed covers a current window; for a full season calendar, use the fixtures feed with a leagueId, and join the two on string match identifiers.