Why you'd need this
Python shows up a lot in sports data work that isn't a web app at all — a backtesting script for a pricing model, a notebook pulling historical results for analysis, a small cron job that checks fixtures every morning. None of that needs a framework. It needs a script that authenticates, hits an endpoint, and gets a usable response back, without a lot of boilerplate in the way.
This is a short walkthrough of doing exactly that with requests, plus a note on where a plain script stops being the right tool.
Getting a key
You need an API key first. Orbistats has a free tier that's enough to build and test something like this without a sales conversation: https://orbistats.com/signup.html
If you want to see the response shape before writing any code, there's a public sandbox that doesn't need an account at all: https://orbistats.com/developers/sandbox.html. Worth doing first, especially if you're about to write a parser for the JSON and don't want to guess at field names.
The script
python
import requests
import os
API_KEY = os.environ["ORBISTATS_API_KEY"]
BASE_URL = "https://api.orbistats.com/v1"
headers = {
"Authorization": f"Bearer {API_KEY}"
}
response = requests.get(f"{BASE_URL}/football/fixtures", headers=headers, timeout=10)
response.raise_for_status()
fixtures = response.json()
for match in fixtures.get("data", []):
print(match)
A note before you copy this: I'm using football/fixtures as the endpoint path based on the documented URL pattern, not a response I've verified directly. Double check the exact path and the shape of fixtures.get("data", []) against the live API reference before this goes anywhere near production, since the actual key names in the response might differ from what I've assumed here.
Keep ORBISTATS_API_KEY as an environment variable, not hardcoded, especially if this script ends up in a repo.
Handling errors without pretending they won't happen
Sports data has real-world failure modes that are easy to skip in a first draft: postponed matches, sports with no fixtures on a given day, rate limits during peak traffic. A slightly more honest version of the loop above:
python
try:
response = requests.get(f"{BASE_URL}/football/fixtures", headers=headers, timeout=10)
response.raise_for_status()
except requests.exceptions.RequestException as e:
print(f"Request failed: {e}")
else:
fixtures = response.json()
if not fixtures.get("data"):
print("No fixtures returned for this query.")
Not exciting, but it's the difference between a script that fails loudly in a way you notice, and one that silently returns nothing and nobody checks why for two weeks.
When a script isn't the right shape anymore
This pattern works fine for anything that runs on a schedule or on demand. It stops working well the moment you need to know about an event the second it happens rather than the next time your script runs, which is most in-play betting or live scoring use cases. At that point you're better off looking at a persistent connection instead of a script that polls on a timer: https://orbistats.com/developers/documentation.html
Where to go from here
This covers one endpoint out of a lot more that's available, including odds, statistics, and historical data. The full reference is worth a browse once the basic script above is working end to end: https://orbistats.com/developers/api-reference.html
Curious how other people structure this in Python once it grows past a single script, do you reach for a small class wrapping the session and auth, or keep it function-based until there's an actual reason not to?
Top comments (0)