ProofOdds

For developers, media and researchers

Use the numbers

There is no API to sign up for, because there is nothing to gate. Every probability this site has ever published is already sitting in a public JSON file, served across origins, with no key and no account — the same bytes the ledger hashes and the same ones anybody uses to check our arithmetic. This page says what is in them, what they are good for, and what is still missing before you could responsibly build a product on top.

What the feed is

One file per publication day, named by date, never rewritten after it is sealed.

curl https://proofodds.com/predictions/2026-09-05.json

What each match carries

Home, draw and away probabilities; both teams to score; a goal-total ladder from 0.5 to 5.5 with over and under on each line; and a quarter-line Asian handicap grid with fair prices and the push probability on every line. All of it derived from one fitted scoreline distribution per match, not from separate models that could disagree with each other.

What each file carries

The divisions covered, the publication timestamp, the hash of the previous entry, this entry's own hash, and the git commit plus source digest of the code that produced the probabilities. A detached OpenTimestamps proof for the same bytes lives under /timestamps/.

1230 forecasts sealed so far across 11 divisions; the most recent entry carries 187. The index lists every file. _chain.json beside them is a build summary, not a ledger entry, and the verifier ignores it.

Be clear about what this is

Reasonable uses

Editorial and broadcast context, where a calibrated probability across 11 divisions is worth more than a pundit's guess and nobody is staking money on the difference. Research. Teaching. And a sealed, dated, independently timestamped baseline to test your own model against — which is hard to obtain anywhere else, because almost nobody publishes forecasts you can prove were not written afterwards.

Not a betting edge

Our own scorecard says the model loses to the market-average closing line, and the walk-forward backtest says it over 2660 matches rather than a lucky few. Anything built on these numbers to beat a bookmaker is starting from a number that is already behind the price. We would rather lose the user than have them find that out with money on it.

What is missing before you build on it

Said here rather than discovered later, because every one of these would matter on the day something broke.

No schema promise

Sealed files are never rewritten, so nothing you already fetched can change under you — but new fields have been added as markets were added and will be again. There is a version on every entry and no commitment yet about what a change to it would mean.

No uptime commitment

This is one virtual machine with a timer on it. The static site survives most things and the ledger is mirrored in a public git repository, but nothing here is operated to a service level and it would be dishonest to imply otherwise.

No history in bulk

The record starts on 26 August 2026 and grows one file a day. There is no archive endpoint and no pre-launch history, because entries generated after the fact are not a track record and this site will not publish them as one.

Licensing is not settled

Our probabilities are ours. The results and closing prices they are graded against come from football-data.co.uk, the fixtures from football-data.org, and neither the accessibility of a feed nor a free tier grants onward commercial rights. If your use is commercial, that is a conversation to have with those sources — and one we are working through ourselves before charging anyone for anything.

If you would actually use this

There is no roadmap here to sign up to, and inventing one before knowing whether anybody wants it is how the wrong thing gets built.

The honest position is that we do not yet know what shape this should take — a documented schema, a historical bulk file, a proper endpoint with an availability promise, or nothing at all beyond the files that already exist. What decides it is whether anyone turns up needing one of them.

So if you would put these numbers in something real, say what you would need and what it is for. A sentence is enough, and a description of the problem is more useful than a feature request.

Tell us what you need