Live football scores API: matches vs scores

Two SportSRC endpoints return fixtures, and the names do not make the difference obvious. Choosing the wrong one produces one of two failures: an app that looks empty, or an app that shows hundreds of matches nobody can watch.

Here is the actual distinction.

The one-line answer

	matches	scores
Contains	Only fixtures with a stream	Every fixture for the day
Grouped by	League	League
Plan	Free & Premium	Premium only
Typical size	Small subset	Everything played
Use for	A watch-focused product	A full live-score product

Why matches is so much smaller

On any given day the world plays a lot of football — several hundred fixtures across every tier and continent. Only a fraction of those carry a stream source that SportSRC can list.

That is not a gap in the data. It is the point of the endpoint. matches exists to answer “what can my users watch right now?” and returning a fixture nobody can watch would be noise.

So if you call matches and get far fewer fixtures than you expected, nothing is broken. You asked for the watchable subset, and that is what arrived.

Pick by product, not by preference

You are building a streaming front end

Use matches. Every fixture it returns is one your user can actually open, so your list never contains a dead end. It is on the free tier, so you can ship before you pay.

GET https://api.sportsrc.org/v3/?type=matches&sport=football

Narrow it with status when you want one state:

GET https://api.sportsrc.org/v3/?type=matches&status=inprogress

You are building a live-score product

Use scores. Users expect to find any match, not only the ones with a stream. Each match still carries has_stream, so you can mark the watchable ones with an icon and keep the rest as scores.

GET https://api.sportsrc.org/v3/?type=scores&date=2026-10-23

This is the combination most products actually want: the full fixture list, with the watchable ones visibly flagged.

A trap worth knowing: dates and time zones

Fixture dates are UTC. A South American match that kicks off at 23:30 UTC belongs to that date, but it finishes on the next one. If you fetch only “today” by your local calendar, those matches vanish from your list while they are still being played.

If your audience spans the Americas, request the neighbouring date as well and merge, or rely on scores without a date parameter, which already carries fixtures in play regardless of which UTC date they started on.

Symptom to watch for: a match disappearing from your UI mid-second-half, around midnight UTC. That is almost always a date-window bug, not a data problem.

Polling without wasting quota

Both endpoints cost one request per call. Quota is counted per API key and resets at 00:00 UTC, and the response carries the running total so you never have to guess:

Header	Meaning
X-RateLimit-Limit	Requests allowed per day
X-RateLimit-Remaining	Requests left today
X-Plan	Your current plan

Two habits keep usage flat however much traffic you get:

• Poll once on your server, not once per visitor. Fetch on an interval, cache the result, and serve every visitor from your cache. A thousand concurrent users then cost the same as one.
• Slow down when nothing is live. If no fixture is in play, a fast interval buys nothing. Check status first and back off overnight.

What neither endpoint gives you

Both return fixture-level data: teams, score, status, timer, flags. For line-ups, statistics, timelines, head-to-head or odds you call the per-match endpoints with the match id from these responses.

Those per-match endpoints only serve fixtures that have a stream. See the guide to has_stream for why, and how to tell in advance which requests will succeed.

Summary

• matches → watchable fixtures only, free tier, small.
• scores → every fixture, premium, with has_stream on each.
• Same cost per call; the difference is access and payload.
• Watch the UTC date boundary if your audience spans the Americas.
• Cache on your server so traffic growth does not grow your quota.