Build on FDVS data directly.
A REST API covering the same fixtures, ratings, consensus and results shown across the platform — for anyone building their own tool, dashboard, or automation on top of it, rather than reading it off a page.
Available endpoints
/v1/fixtures
Today's, tomorrow's, or weekend fixtures — consensus, kickoff time, and league, for any tracked competition.
/v1/teams/:id/ratings
The full six-axis breakdown for a specific club — the same numbers behind that team's own analysis page.
/v1/fixtures/:id/analysis
The complete match analysis for one fixture — odds comparison, market ratings, radar data, all in one response.
/v1/results
Settled results for any date range, with the graded verdict included — the same data behind the results archive.
/v1/rankings/club
The current Club Rankings leaderboard, or Power Rankings for momentum-weighted movement instead of absolute strength.
/v1/prime-picks
Today's live Prime Picks — fixture, market and odds for each, without the locked written analysis.
A sample request
Request
GET https://api.fdvs.org/v1/fixtures/8841/analysis Authorization: Bearer YOUR_API_KEY
Response
{
"fixture_id": 8841,
"home": "Man City",
"away": "Newcastle",
"league": "Premier League",
"kickoff": "2026-08-13T17:30:00Z",
"consensus": {
"home_win_pct": 61,
"sources_tracked": 36
},
"market_ratings": {
"over_1_5_goals": 95,
"btts_yes": 65
}
}
Authentication & rate limits
Common questions
Where do I get an API key?
Once you're on Pro, a key is generated from your account settings. Every request needs it in the Authorization header — requests without a valid key are rejected before hitting any endpoint.
What happens if I go over the rate limit?
Requests beyond 120 per minute return a rate-limit error rather than being queued or silently dropped — the response tells you exactly when the limit resets so you can back off and retry cleanly.
Can I get historical data, or only current fixtures?
The results endpoint accepts a date range and returns settled fixtures for any period currently available on the historical results page — not limited to today's board.
Does the API include the locked Prime Pick analysis?
No — the Prime Picks endpoint returns the same public fixture, market and odds shown on the Prime Picks page. The written analysis itself is only available after unlocking that specific pick, the same as on the site.
Is there a sandbox or test mode?
Not currently — every request hits live data. Since all the underlying data is already free to view on the site itself, there's been less need for a separate sandbox than a typical payments API would require.
Why API access is a different feature from data exports, not a bigger version of it
One gives you a fixed copy to keep; the other gives you a live feed to build against — different tools for genuinely different jobs, not two sizes of the same thing.
Data Exports gives you a fixed snapshot to keep — a match report as it stood at one moment. The API gives you the same underlying data as a live, queryable feed, meant to be pulled automatically rather than downloaded manually one fixture at a time. They solve different problems for genuinely different kinds of use, and neither one is a scaled-up or scaled-down version of the other — reaching for the wrong one just because it's more familiar would be a poor fit either way.
Who the API is actually for
If you're building your own tool — a personal dashboard, a script that checks specific fixtures automatically, a spreadsheet that refreshes itself — the API is built for that. If you just want to read FDVS's own breakdown of a fixture, the site itself is a better fit than writing code to fetch and parse a response you could see directly on the page. The API isn't meant to replace the site for everyday use, only to serve the specific case where you want the data flowing into something you're building rather than displayed on a page you're reading. Most people using FDVS will never need it, and that's completely fine — it's a deliberately narrow feature for a specific kind of user, not something everyone on Pro is expected to touch.
Why the rate limit exists at all
120 requests per minute is generous for almost any reasonable use case — checking today's fixtures, pulling a specific team's ratings, watching a handful of matches update live. The limit exists to keep the API stable for everyone using it, not to restrict any normal use down to something impractical. A limit that's too tight would make the API frustrating to build against; one that's effectively unlimited would risk the exact stability problem the limit is meant to prevent in the first place — 120 per minute is well past what any reasonable personal script would ever need to hit in normal operation.
Why JSON only, no other formats
JSON is the practical default for a REST API — nearly every programming language and tool can parse it without additional setup, unlike XML or a custom format that would require extra work on your end for no real benefit. Keeping to one well-supported format matters more than offering several less commonly needed ones, and every endpoint on the API returns the same consistent structure rather than switching format conventions from one endpoint to the next, which keeps the response shape predictable no matter which part of the API you're calling.
Why Prime Pick's written case still stays locked via the API
The API mirrors the site's own access rules rather than creating a separate set of them — a Prime Pick's fixture and market are public everywhere, and the written analysis behind it is unlocked the same way regardless of whether you're viewing it on the page or querying it through the API. The API isn't a way around what's paid content elsewhere on the platform; it's the same rules, just accessed a different way, which is exactly the consistency you'd want from a data source you're actually building something on top of.
Why this is included with Pro, not a separate paid add-on
Pro already includes the raw source-level detail and exportable reports — the API is the same underlying access, just queryable rather than manually exported. Splitting it into its own separate paid tier would fragment a single coherent idea — "see and use the deeper data" — into two purchases for what's really one feature expressed two ways. Someone who wants the API almost certainly also wants the source breakdown and the exports, so bundling them together under Pro reflects how they'd actually be used together in practice, rather than forcing an artificial separation between features that naturally belong side by side.
What building against the API typically looks like
A common pattern is pulling the fixtures endpoint each morning to build a personal daily watchlist automatically, then querying the match analysis endpoint for whichever fixtures actually matter that day rather than every single one tracked. The API rewards that kind of targeted, purposeful use — hitting the endpoints you actually need rather than pulling everything just because it's available, which is also the pattern that keeps you well within the rate limit without ever having to think about it. Building something small and genuinely useful tends to work better here than trying to mirror the entire site through the API at once.