I Built a Sports Odds API Because I Was Sick of Fighting Every Other One
A few years ago I started building software around sports betting, and I honestly thought the difficult part would be coming up with profitable models or finding an edge over everyone else. It turned out I was completely wrong. The thing that consumed the most time wasn’t building the actual product, it was trying to get reliable odds data into it.
I tried just about every odds API I could find, and while most of them worked well enough, they all had one thing in common. They expected you to keep asking them whether anything had changed.
If you’re building a hobby project that checks a handful of games every few minutes, that’s completely fine. But once you start monitoring thousands of markets across multiple bookmakers, different sports and dozens of market types, you realise how inefficient that approach really is. Your servers are making request after request after request, most of which come back with exactly the same data as the last one, and before long you’re either running into rate limits or spending money just to find out that nothing has actually happened.
I remember looking through our logs one day and thinking how ridiculous it was. We were making an enormous number of API requests every single day, not because we needed fresh information, but because we had no other way of knowing whether the information had changed. It felt backwards.
That was the point where I stopped looking for another provider and started building our own infrastructure instead.
The idea itself wasn’t particularly revolutionary. Rather than forcing every application to poll continuously, why not let the server push updates whenever odds actually changed? That way an application could request an initial snapshot of the market, open a persistent connection, and then simply sit there waiting for changes instead of asking the same question over and over again.
It sounds like a small architectural decision, but it completely changed the way we built everything else. Instead of rebuilding entire odds screens every few seconds, we only updated the prices that had actually moved. API traffic dropped dramatically, bandwidth usage became far more predictable, and applications felt genuinely live instead of constantly refreshing in the background.
As the project grew, I realised the streaming side was only a small piece of the problem. The real challenge was everything that happens behind the scenes that developers never really think about until it breaks. Every bookmaker structures data differently, markets disappear and reappear, team names aren’t consistent, player markets are represented in different ways, and identifiers change constantly. A huge amount of development time ended up being spent normalising data so developers using the API didn’t have to deal with that complexity themselves.
That philosophy has shaped pretty much every decision we’ve made since. I don’t want developers spending days reading documentation or writing adapters just to consume odds data. I want someone to be able to make a request, receive predictable JSON, subscribe to live updates if they need them, and get back to building the product they actually care about.
The project eventually became Odds-API.net, and while it’s still evolving every week, it started because of a fairly simple frustration: I got tired of spending more time working around odds APIs than actually building software with them.
I’d be interested to hear how other developers have approached this problem. Are you still polling every few seconds, or have you moved towards streaming or another architecture altogether?
