Why "just add live scores" is harder than it sounds
If you've ever tried to bolt live sports scores onto a side project, a fan site, a Discord bot, a fantasy league tracker, you've probably hit the same wall: there's no built-in browser API for "what's the score right now." You either scrape a page (fragile, against most sites' terms, breaks the moment the markup changes) or you find a proper sports data API and work with structured JSON instead.
The second path is more reliable, but "find a sports data API" is where a lot of people get stuck, mostly because there's no single obvious starting point and every provider names things slightly differently. This is a beginner-level map of the landscape: what these APIs actually give you, how free tiers usually work, and the three common ways you'll end up consuming the data depending on what you're building.
What you actually get from a sports data API
Strip away the marketing pages and most sports data APIs boil down to a handful of resource types:
- Fixtures/schedules — what's playing, when, in which competition
- Live scores — the current state of an in-progress match
- Standings — league tables, points, rankings
- Stats and events — goals, cards, substitutions, play-by-play depending on depth
You query these over plain HTTP and get JSON back. Orbistats covers this shape of data with a free tier to get started, no credit card needed to try it: https://orbistats.com/signup.html
If you want to see what's actually possible before committing to an approach, it's worth skimming the full developer documentation first: https://orbistats.com/developers/documentation.html
Three ways to consume it, depending on what you're building
Once you have an API key from https://orbistats.com/signup.html, there isn't one "correct" way to use it, it depends on what you're building.
If you're building a full app or backend service, you'll want to hit the REST endpoints directly and shape the response however your app needs it. This gives you full control but means you own the polling/caching logic yourself.
const response = await fetch("https://api.orbistats.com/v1/fixtures?date=2026-09-17", {
headers: { "Authorization": "Bearer YOUR_API_KEY" }
});
const fixtures = await response.json();
console.log(fixtures);
As with any API, double-check the exact endpoint paths and auth header format against the real REST API reference before you build against them: https://orbistats.com/developers/api-reference.html. I also walked through a fuller REST consumption example in C#/.NET Core if that's your stack: consuming a sports data API in .NET Core.
If you just need a scoreboard on a page without writing a rendering layer yourself, a drop-in embed widget is usually the fastest path, script tag, container div, done. There's a live preview of what it looks like on the widgets page: https://orbistats.com/widgets.html, and I covered the full setup in a previous post: adding a live score widget without building a frontend.
If your app needs sub-second updates (a live betting-adjacent UI, a big shared display, anything where a few seconds of lag is noticeable), polling a REST endpoint on an interval starts to strain both your rate limit and your UX. That's the case for a push-based connection instead, covered in the WebSocket section of the docs (https://orbistats.com/developers/documentation.html) and in more depth in a dedicated post: getting real-time scores with WebSockets instead of polling.
Free tier gotchas worth knowing upfront
A few things that trip people up on free tiers specifically, across sports data providers in general, not just one:
-
Rate limits are usually per-minute, not just per-day — a
setIntervalpolling every second will exhaust a free tier fast. Start with a slower interval than you think you need. - Not every sport/league is covered at every tier — niche leagues and lower divisions are often gated behind paid plans even when major leagues are free.
- Historical data is often separate from live data — a free tier that gives you today's scores may not give you last season's results without an upgrade.
None of these are unique to Orbistats, it's just how usage-based data APIs are generally structured. The signup page lists what's actually included at the free tier: https://orbistats.com/signup.html, and the full reference has the per-endpoint limits if you want to plan around them before you architect anything: https://orbistats.com/developers/api-reference.html
Picking your starting point
If you're not sure which of the three approaches above fits your project: start with the widget (https://orbistats.com/widgets.html) if you want something on screen today, move to REST (https://orbistats.com/developers/api-reference.html) if you're building real app logic around the data, and only reach for WebSockets once polling has actually become a measurable problem, not before. Premature real-time is a common trap, most side projects genuinely don't need sub-second updates. The full documentation covers all three paths side by side if you want to compare before picking: https://orbistats.com/developers/documentation.html
Where to go from here
Everything referenced in this post, in one place:
- Sign up for a free API key: https://orbistats.com/signup.html
- Full developer docs (REST, WebSocket, widgets): https://orbistats.com/developers/documentation.html
- REST API reference: https://orbistats.com/developers/api-reference.html
- Widget preview and setup: https://orbistats.com/widgets.html
- Related posts: adding a live score widget, .NET Core REST example, real-time scores with WebSockets
What are you building live scores into? Curious what's driving people to reach for this in the comments, fan projects, internal dashboards, something else entirely.

Top comments (0)