DEV Community: orbistats

9 Things to Check Before You Build on a Sports Data API (Python Examples)

orbistats — Thu, 17 Sep 2026 17:56:49 +0000

Why this checklist exists

Picking a sports data API usually happens fast, you sign up, copy a curl example from the docs, and start building. Then two weeks in you discover the rate limit resets hourly instead of daily, or the league you need is behind a paid tier, or live updates lag by 90 seconds because you're polling too slowly. None of that shows up on the landing page.

This is the list I wish I'd checked before, not after, picking a provider. Examples below use Orbistats (https://orbistats.com/developers/documentation.html) since that's what I've been building against, but the checklist itself applies to evaluating any sports data API.

1. Does the free tier actually cover your sport and league?

Coverage claims are usually "30+ sports" on the homepage, but free tiers often gate everything except the two or three biggest leagues. Check the actual free-tier scope before assuming your niche league is included: https://orbistats.com/signup.html

2. What's the real rate limit, per minute or per day?

This is the one that breaks side projects. A limit quoted as "10,000 requests/day" sounds generous until you realize it might also cap out at 20/minute, which a naive polling loop blows through in under a minute. Check the per-endpoint limits in the API reference, not just the marketing number: https://orbistats.com/developers/api-reference.html

import requests
import time

API_KEY = "YOUR_API_KEY"
headers = {"Authorization": f"Bearer {API_KEY}"}

def get_live_scores(sport="football"):
    response = requests.get(
        f"https://api.orbistats.com/v1/live?sport={sport}",
        headers=headers
    )
    response.raise_for_status()
    return response.json()

# Poll every 30s, not every 1s, until you've confirmed your actual rate limit
while True:
    scores = get_live_scores()
    print(scores)
    time.sleep(30)

The endpoint path and query parameter above follow common REST convention, verify the real ones against the docs before you build against them: https://orbistats.com/developers/api-reference.html

3. Is there a push option, or is polling your only choice?

If you eventually need sub-second updates, find out now whether the provider offers a WebSocket or SSE stream, retrofitting push-based updates onto an app built entirely around polling is more work than building it in from the start. I covered this specific trade-off in more depth here: getting real-time scores with WebSockets instead of polling.

4. Do you need a full backend, or would a widget cover it?

Not every project needs raw API access. If you just need a scoreboard visible on a page and nothing more, an embeddable widget skips the backend entirely, worth checking before you write a single fetch call: https://orbistats.com/widgets.html. Full walkthrough here: adding a live score widget without building a frontend.

5. What does the response shape actually look like?

Docs pages show idealized examples. Pull a real response for an in-progress match and check what fields are actually populated versus null, especially for stats-heavy fields, before you build UI around data that might not always be there.

6. How is authentication handled, and does it change per environment?

Bearer token in a header is common, but confirm whether sandbox/free-tier keys behave differently from production keys, and whether there's a separate key per environment. Getting this wrong is a common source of "works locally, breaks in prod."

7. What happens when a match is postponed or has no data yet?

Edge cases matter more in sports data than most APIs, postponed matches, abandoned matches, matches with incomplete stats. Check whether the API returns an explicit status field for this or just omits fields silently, the latter is much easier to build broken UI around.

8. Is there a language/SDK example close to your stack?

Raw REST works everywhere, but a maintained example in your language saves time on auth boilerplate and error handling. If you're in the .NET ecosystem, there's a full REST consumption walkthrough here: consuming a sports data API in .NET Core.

9. What's the actual upgrade path when you outgrow free tier?

Worth knowing before you're mid-launch and suddenly rate-limited. Check what the next tier unlocks, more requests, more leagues, or both, so scaling isn't a surprise: https://orbistats.com/signup.html

Putting it together

None of these nine are deal-breakers on their own, but checking them upfront turns "which sports data API should I use" from a five-minute landing-page decision into a five-minute decision you can actually defend later. The full docs cover all of this in one place if you want to work through the checklist directly against a real provider: https://orbistats.com/developers/documentation.html

What's on your list that isn't here? Curious what's bitten people in production that a checklist like this wouldn't have caught.

How to Get Live Sports Scores for Free: A Beginner's Guide to Sports Data APIs

orbistats — Thu, 17 Sep 2026 17:50:17 +0000

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 setInterval polling 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.

Getting Real-Time Scores with WebSockets Instead of Polling

orbistats — Thu, 17 Sep 2026 17:39:41 +0000

Why polling stops working

If you've built a live scoreboard before, you probably started with a setInterval hitting a REST endpoint every few seconds. That works fine for a handful of users checking a handful of matches. It stops working the moment you have real traffic, because every refresh is a new request, most of which return nothing new, and your rate limit burns down whether the score changed or not.

A push-based connection flips that around: the server tells you when something changes instead of you asking repeatedly. For live sports specifically, this matters a lot, since a goal or a point can happen at any second and users notice lag immediately.

Before you start

You'll need an API key for this, same as the REST endpoints. Orbistats' free tier covers WebSocket access too: https://orbistats.com/signup.html

Worth reading the WebSocket section of the docs before wiring this up, since message shapes and event names are the kind of detail you want confirmed rather than guessed: https://orbistats.com/developers/documentation.html

Opening the connection

The general shape of this kind of integration is a WebSocket connection you authenticate on open, then subscribe to specific matches or a whole sport feed. Something like:

const socket = new WebSocket("wss://api.orbistats.com/v1/stream?api_key=YOUR_API_KEY");

socket.addEventListener("open", () => {
  socket.send(JSON.stringify({
    action: "subscribe",
    channel: "football",
    match_id: "match_50231"
  }));
});

socket.addEventListener("message", (event) => {
  const update = JSON.parse(event.data);
  console.log(update);
});

A note before you copy this: the connection URL, the subscribe message shape, and the field names above are written from the general convention for this kind of sports data stream, not a confirmed payload I've inspected directly. Some providers key subscriptions by sport, others by a single match id, others let you subscribe to both at once. Confirm the exact message format in the docs before you build around it: https://orbistats.com/developers/documentation.html

Handling reconnects

This is the part polling never made you think about. A WebSocket connection can drop for all kinds of reasons unrelated to your code, a laptop going to sleep, a flaky mobile network, a load balancer cycling connections. If you don't handle reconnects, your scoreboard just silently stops updating and nobody notices until someone complains.

A basic reconnect loop with backoff:

function connect() {
  const socket = new WebSocket("wss://api.orbistats.com/v1/stream?api_key=YOUR_API_KEY");
  let retryDelay = 1000;

  socket.addEventListener("open", () => {
    retryDelay = 1000; // reset backoff once we're actually connected
  });

  socket.addEventListener("close", () => {
    setTimeout(connect, retryDelay);
    retryDelay = Math.min(retryDelay * 2, 30000);
  });

  return socket;
}

Whether the server also sends you a snapshot on reconnect, or expects you to re-subscribe from scratch, is exactly the kind of detail that varies between providers and is worth confirming rather than assuming.

Falling back to REST

Not every environment plays nicely with long-lived WebSocket connections, some corporate networks and proxies block them outright. Having a REST fallback that polls at a slower interval when the socket fails to connect a few times in a row is a reasonable safety net rather than leaving users with a scoreboard that just never loads.

When polling is still fine

None of this means polling is wrong by default. If you're showing scores that update every few minutes rather than every few seconds, or you're building something low-traffic and the added complexity of connection state, reconnects, and subscription management isn't worth it yet, a simple interval-based fetch against the REST API is still the pragmatic choice. Full REST reference here: https://orbistats.com/developers/api-reference.html

Where to go from here

This covers the raw WebSocket path. If you'd rather skip building the UI around it entirely, there's also a drop-in live score widget that handles the connection and rendering for you: https://orbistats.com/widgets.html

Curious how others here are handling reconnect logic in production, exponential backoff, a fixed retry count, something else?

Adding a Live Score Widget to Any Website Without Building a Frontend

orbistats — Thu, 17 Sep 2026 17:21:37 +0000

Why you'd want this

Most tutorials on sports data APIs walk you through fetching JSON and rendering it yourself, which makes sense if you are building something custom. But a lot of the time you don't need custom. You need a live scoreboard sitting on a page, today, without a frontend sprint attached to it, and you'd rather not own the WebSocket reconnect logic for something that is not your core product.

This is a quick walkthrough of embedding a live score widget directly into a page with a script tag, instead of building the scoreboard UI from raw API responses.

Before you start

You'll want an API key even for the widget, since it authenticates the feed behind the scenes. Orbistats has a free tier that covers this: https://orbistats.com/signup.html

If you want to see what the widget looks like before wiring it into your own page, there's a preview on the widgets page itself: https://orbistats.com/widgets.html

The embed

The general pattern for this kind of widget is a small script tag plus a container element it mounts into. Something like this:

html

Check the exact snippet on the widgets page before shipping it, since widget embed conventions can vary slightly: https://orbistats.com/widgets.html

Match center instead of just scores

If a single scoreboard isn't enough and you want a full match center, drilling into one game with stats and events, the pattern is the same idea with a different widget type and a match identifier instead of a sport-wide feed:

html

You'd get the match id the same way you'd get one from the REST API, by listing fixtures for the day and picking the one you want to display.

Styling it to fit your page

Drop-in widgets are only useful if they don't look like they were dropped in. Most implementations expose a handful of CSS variables or a theme parameter for background, text color, and accent color rather than full style overrides, since that keeps the underlying markup stable across updates. Worth checking what's exposed before assuming you need to fight the widget with your own CSS overrides.

When to skip the widget entirely

If you already have a design system the scoreboard needs to sit inside pixel-for-pixel, or you need interactions the widget doesn't support, hand-rolling it against the REST or WebSocket API directly is the better call. The widget buys you speed, not infinite flexibility. Full API reference if that's the route: https://orbistats.com/developers/api-reference.html

Where to go from here

This covers embedding, not building your own from the raw feed. If you want that version instead, the developer docs cover both the REST and WebSocket paths depending on how live you need it: https://orbistats.com/developers/documentation.html

Curious if anyone here has gone the widget route and later ripped it out for a custom build, or the other way around. What was the actual trigger for switching?

Consuming a Sports Data API in Go with net/http

orbistats — Thu, 17 Sep 2026 13:47:47 +0000

# Consuming a Sports Data API in Go with net/http

When you build a sports application in Go, the HTTP request itself is usually the easy part.

The harder part is turning an external sports feed into something your application can use reliably: authentication, JSON decoding, pagination, rate limits, error handling, and eventually real-time updates all become part of the integration.

In this tutorial, we'll build a small Go client for the Orbistats sports data API using Go's standard net/http package. The goal is to keep the example small enough to understand, while still showing patterns you can reuse in a larger service.

What we're building

The example will:

Read an Orbistats API key from an environment variable.
Send a Bearer-authenticated request from Go.
Request football fixtures.
Decode the JSON response into Go structs.
Handle non-2xx HTTP responses.
Leave the client structure ready for additional endpoints.

The base API URL is:

https://api.orbistats.com/v1/

Orbistats documents Bearer-token authentication for API requests.

1. Get an API key

For authenticated API requests, create a free account and generate an API key:

https://orbistats.com/signup.html

You can also experiment with the public sandbox before creating an account:

https://orbistats.com/developers/sandbox.html

For local development, keep the API key in an environment variable instead of committing it to source control.

On Linux/macOS:

export ORBISTATS_API_KEY="your_api_key_here"

On Windows PowerShell:

$env:ORBISTATS_API_KEY="your_api_key_here"

Avoid putting the key directly into a Go source file, especially if the repository will be public.

2. Create a Go project

Create a new directory and initialize a module:

mkdir orbistats-go-example
cd orbistats-go-example

go mod init example.com/orbistats-go-example

This example uses only Go's standard library, so there are no third-party HTTP dependencies to install.

3. Define the response types

A useful property of Go is that JSON can be decoded directly into structs.

A simplified fixture response can be represented like this:

package main

type Fixture struct {
    FixtureID  string `json:"fixture_id"`
    HomeTeam   string `json:"home_team"`
    AwayTeam   string `json:"away_team"`
    Kickoff    string `json:"kickoff"`
    Competition string `json:"competition"`
}

type Meta struct {
    Sport string `json:"sport"`
    Count int    `json:"count"`
}

type Pagination struct {
    Page         int `json:"page"`
    PerPage      int `json:"per_page"`
    TotalPages   int `json:"total_pages"`
    TotalResults int `json:"total_results"`
}

type FixturesResponse struct {
    Data       []Fixture  `json:"data"`
    Meta       Meta       `json:"meta"`
    Pagination Pagination `json:"pagination"`
}

The important part is the JSON tag.

For example:

FixtureID string `json:"fixture_id"`

tells Go's JSON decoder that the API field fixture_id should populate the FixtureID field.

If the API returns additional fields that your application does not need yet, you don't have to model every field immediately.

4. Make the authenticated request

Now we can create a small function that calls the fixtures endpoint.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
)

const baseURL = "https://api.orbistats.com/v1"

func getFixtures(apiKey string) (*FixturesResponse, error) {
    req, err := http.NewRequest(
        http.MethodGet,
        baseURL+"/football/fixtures",
        nil,
    )
    if err != nil {
        return nil, err
    }

    req.Header.Set("Authorization", "Bearer "+apiKey)
    req.Header.Set("Accept", "application/json")

    client := &http.Client{}

    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        body, _ := io.ReadAll(resp.Body)

        return nil, fmt.Errorf(
            "Orbistats API returned %s: %s",
            resp.Status,
            string(body),
        )
    }

    var result FixturesResponse

    if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
        return nil, err
    }

    return &result, nil
}

func main() {
    apiKey := os.Getenv("ORBISTATS_API_KEY")

    if apiKey == "" {
        fmt.Println("ORBISTATS_API_KEY is not set")
        os.Exit(1)
    }

    result, err := getFixtures(apiKey)
    if err != nil {
        fmt.Println("Request failed:", err)
        os.Exit(1)
    }

    fmt.Printf("Sport: %s\n", result.Meta.Sport)
    fmt.Printf("Fixtures returned: %d\n", result.Meta.Count)

    for _, fixture := range result.Data {
        fmt.Printf(
            "%s vs %s — %s\n",
            fixture.HomeTeam,
            fixture.AwayTeam,
            fixture.Kickoff,
        )
    }
}

Run it with:

go run .

The important authentication line is:

req.Header.Set("Authorization", "Bearer "+apiKey)

That is the same Bearer-token pattern you can reuse for other Orbistats API requests.

5. Why handle HTTP errors before decoding JSON?

It can be tempting to immediately decode every response into your success struct.

In production code, it's better to inspect the status first:

if resp.StatusCode < 200 || resp.StatusCode >= 300 {
    body, _ := io.ReadAll(resp.Body)

    return nil, fmt.Errorf(
        "Orbistats API returned %s: %s",
        resp.Status,
        string(body),
    )
}

That gives you a useful distinction between:

a successful response with data,
an authentication failure,
a bad request,
a missing resource,
a rate-limit response,
and a server-side error.

For example, if the API key is invalid, the API can return an HTTP 401 response. A 429 response indicates that the request rate has exceeded the applicable limit.

Your application can then decide whether to return an error to the caller, retry, or back off.

6. Add query parameters

Most useful sports applications eventually need filtering.

For example, instead of constructing a URL manually, Go's net/url package can safely build query parameters:

package main

import "net/url"

func addDateFilter(base string, date string) string {
    u, err := url.Parse(base)
    if err != nil {
        return base
    }

    q := u.Query()
    q.Set("date", date)
    u.RawQuery = q.Encode()

    return u.String()
}

You could then build a request URL such as:

https://api.orbistats.com/v1/football/fixtures?date=2026-09-14

This is preferable to manually concatenating strings when an application has multiple optional filters.

The API documentation also describes common parameters such as date, season, team_id, competition_id, page, and per_page.

7. Think about pagination early

A sports API can return more fixtures than you want to process in a single request.

A typical list response includes pagination information, for example:

{
  "data": [],
  "meta": {
    "sport": "football",
    "count": 25
  },
  "pagination": {
    "page": 1,
    "per_page": 25,
    "total_pages": 4,
    "total_results": 87
  }
}

A simple pagination loop in Go could look like:

for page := 1; page <= totalPages; page++ {
    // Request the current page.
    // Process result.Data.
    // Continue until all pages are handled.
}

For a production service, I would put pagination inside the API client rather than making every caller understand the API's pagination rules.

That gives the rest of your application a simpler interface:

fixtures, err := client.ListFixtures(ctx, filters)

instead of making business logic responsible for HTTP details.

8. Keep the API client separate from application logic

Once the integration grows, a useful project structure might look like this:

orbistats-go-example/
├── go.mod
├── main.go
├── orbistats/
│   ├── client.go
│   ├── fixtures.go
│   └── errors.go
└── internal/
    └── ...

The orbistats package can own:

authentication headers,
request construction,
JSON decoding,
pagination,
API errors,
retries/backoff where appropriate.

Your application code can then work with Go types instead of raw HTTP responses.

This separation becomes especially useful if the same sports data is consumed by multiple parts of a service.

9. Polling vs WebSocket for live sports data

For scheduled fixtures or data that changes relatively slowly, normal HTTP requests are straightforward.

Live scores and odds are different.

A basic polling model looks like:

Your service
     |
     | GET /football/...
     v
Orbistats
     |
     | JSON response
     v
Your service

You repeat that request on a timer.

Polling is simple, but the interval creates a trade-off:

Poll too frequently and you make unnecessary requests.
Poll too slowly and your application can display stale data.

For live applications, a push-based architecture can be a better fit.

Orbistats documents two real-time approaches: webhooks for event-driven updates and a WebSocket API for a persistent streaming connection.

A WebSocket model looks more like:

Your service
     |
     | persistent connection
     v
Orbistats stream
     |
     +---- update
     +---- update
     +---- update

If you are building a live score board, notification system, or another application where updates need to arrive continuously, compare the polling, webhook, and WebSocket approaches in the Orbistats documentation:

https://orbistats.com/developers/documentation.html

For many applications, a practical architecture is to use ordinary REST requests for initial state and historical/scheduled data, then use a real-time mechanism for subsequent updates.

10. A small production checklist

Before turning this example into a production integration, I would add:

A shared http.Client instead of creating one per request.
Request timeouts.
Context cancellation with context.Context.
Structured application logging.
Explicit handling for 401, 403, 404, and 429.
Backoff for retryable failures.
Pagination helpers.
Metrics for request latency and error rates.
Tests using an httptest.Server.
Environment-based configuration for API credentials.
Protection against accidentally logging the Bearer token.

For example, using a timeout:

client := &http.Client{
    Timeout: 10 * time.Second,
}

And in a larger application, prefer a context-aware request:

req, err := http.NewRequestWithContext(
    ctx,
    http.MethodGet,
    url,
    nil,
)

That allows the request to stop when the surrounding operation is cancelled.

11. Where to go from here

Once the basic Go client works, the same pattern can be extended to fixtures, results, standings, statistics, odds, teams, players, competitions, and other resources supported by the API.

The full endpoint list, parameters, response fields, pagination details, and real-time references are available in the Orbistats API reference:

https://orbistats.com/developers/api-reference.html

The main idea is to keep the HTTP layer small and predictable. Go's standard library already provides most of what you need to make the first integration without adding an SDK or HTTP framework.

Consuming a Sports Data API in Python (Requests + FastAPI Example)

orbistats — Thu, 17 Sep 2026 13:26:45 +0000

A lot of sports-data tutorials assume you're building a frontend widget, but plenty of us just need this data flowing into a backend service — a Discord bot, a Telegram alert, an internal dashboard, whatever. Here's how to pull live football scores in Python and expose them through a tiny FastAPI wrapper of your own.

Why wrap it at all

You could call the API directly from wherever you need the data, but wrapping it behind your own FastAPI endpoint gives you a place to cache responses, add your own auth, or reshape the data before it hits your frontend — without every client needing to know about your upstream API key.

Setup

Grab a free API key first (no card needed): sign up here. If you'd rather see what the raw responses look like before writing any code, there's a public sandbox: orbistats.com/developers/sandbox.html

Install what you need:

pip install requests fastapi uvicorn python-dotenv

Store your key in a .env file rather than hardcoding it:

ORBISTATS_API_KEY=your_key_here

Step 1: A small client function

import os
import requests
from dotenv import load_dotenv

load_dotenv()

API_KEY = os.getenv("ORBISTATS_API_KEY")
BASE_URL = "https://api.orbistats.com/v1"

def get_live_football_scores():
    response = requests.get(
        f"{BASE_URL}/football/live",
        headers={"Authorization": f"Bearer {API_KEY}"}
    )
    response.raise_for_status()
    return response.json()

Calling it directly gives you something like:

matches = get_live_football_scores()
for match in matches:
    home = match["home"]["name"]
    away = match["away"]["name"]
    print(f"{home} {match['home']['score']} - {match['away']['score']} {away} ({match['minute']}')")

Step 2: Wrap it in FastAPI

from fastapi import FastAPI

app = FastAPI()

@app.get("/scores/live")
def live_scores():
    return get_live_football_scores()

Run it with uvicorn main:app --reload and you've got your own /scores/live endpoint that your frontend, bot, or internal tool can hit without ever touching the upstream key directly.

Caching so you don't burn through your rate limit

Since live scores don't change every second, a simple in-memory cache with a short TTL keeps you well within free-tier limits:

from cachetools import TTLCache

cache = TTLCache(maxsize=1, ttl=15)

@app.get("/scores/live")
def live_scores():
    if "matches" not in cache:
        cache["matches"] = get_live_football_scores()
    return cache["matches"]

Polling vs WebSockets

This pattern works fine for polling every 15-30 seconds. If you need genuinely real-time push updates instead of polling — say for a live odds board — it's worth looking at the WebSocket API rather than repeatedly hitting REST: documentation here

Wrapping up

Same pattern extends to fixtures, results, historical data, and odds — just swap the endpoint path and response shape. Full list of what's available is in the API reference.

Anyone else building small backend wrappers like this instead of calling third-party APIs directly from the frontend? Curious what caching strategies people land on for data that updates every few seconds.

Consuming a Sports Data API in .NET Core (C# Example)

orbistats — Thu, 17 Sep 2026 13:16:43 +0000

Most sports-data API tutorials out there are written for JavaScript, so here's the .NET Core version — useful if you're building a backend service, a Blazor app, or just prefer typed responses over parsing raw JSON by hand.

This walks through pulling live football scores using HttpClient and System.Text.Json.

Setup

Create a free API key first — no card required for the free tier: sign up here. If you want to see raw responses before writing any code, there's a public sandbox too: orbistats.com/developers/sandbox.html

Add your key to appsettings.json or user secrets rather than hardcoding it:

{
  "OrbistatsApiKey": "YOUR_API_KEY"
}

Step 1: Create a typed client

public class OrbistatsClient
{
    private readonly HttpClient _httpClient;

    public OrbistatsClient(HttpClient httpClient, string apiKey)
    {
        _httpClient = httpClient;
        _httpClient.BaseAddress = new Uri("https://api.orbistats.com/v1/");
        _httpClient.DefaultRequestHeaders.Authorization =
            new AuthenticationHeaderValue("Bearer", apiKey);
    }

    public async Task<List<LiveMatch>> GetLiveFootballScoresAsync()
    {
        var response = await _httpClient.GetAsync("football/live");
        response.EnsureSuccessStatusCode();

        var stream = await response.Content.ReadAsStreamAsync();
        var matches = await JsonSerializer.DeserializeAsync<List<LiveMatch>>(stream);

        return matches ?? new List<LiveMatch>();
    }
}

Step 2: Define the response model

public class LiveMatch
{
    [JsonPropertyName("match_id")]
    public string MatchId { get; set; } = string.Empty;

    public string Status { get; set; } = string.Empty;
    public int Minute { get; set; }

    public TeamScore Home { get; set; } = new();
    public TeamScore Away { get; set; } = new();
}

public class TeamScore
{
    public string Name { get; set; } = string.Empty;
    public int Score { get; set; }
}

Step 3: Register and use it

If you're using dependency injection (most ASP.NET Core apps are), register it in Program.cs:

builder.Services.AddHttpClient<OrbistatsClient>();
builder.Services.AddSingleton(sp =>
    new OrbistatsClient(
        sp.GetRequiredService<HttpClient>(),
        builder.Configuration["OrbistatsApiKey"]!
    )
);

Then wherever you need it:

var matches = await orbistatsClient.GetLiveFootballScoresAsync();

foreach (var match in matches)
{
    Console.WriteLine($"{match.Home.Name} {match.Home.Score} - {match.Away.Score} {match.Away.Name} ({match.Minute}')");
}

A note on polling vs WebSockets

For most side projects, polling this every 15-30 seconds on a background service (IHostedService or a simple timer) is enough and keeps you comfortably within free tier limits. If you need true real-time push updates instead — say, for a live trading dashboard — it's worth checking the WebSocket API instead of polling REST repeatedly: documentation here

Wrapping up

That covers the basic flow — auth, typed client, DI registration, and consuming the response. The same pattern works for the other endpoints (fixtures, results, odds, historical data), you'd just swap the model class and the endpoint path. Full list is in the API reference.

Would be curious if anyone here has a cleaner pattern for typed API clients in .NET — always looking to simplify this kind of boilerplate.