Growing Discord community — direct access to the developer, live coverage & picks. Join the Discord Join now →

An availability flag per market, like `has_xg`

Feature Request Football Resolved 🎖️ 1 Founder vote 100% Sep 14, 2026 · srfcboy · 🥵 61 aura
An availability flag per market, like `has_xg` I had to guess or use trial and error to find out if corners, cards, etc., were available for a given match. A `has_corners_odds`, `has_cards_stats`, etc., would avoid making "empty" calls just to check.
Resolution: Shipped as /api/v2/events/{id}/availability/ — computed at read time, not a stored flag.

Comments

2
Bzzoiro · Admin Sep 17, 2026 06:13
Hi, Reasonable ask, and no, not for now. Availability flags per market mean computing and serving presence for corners, cards, odds and the rest on every match, which is a new field set to keep honest across the whole fixture list - and a flag that goes stale is worse than an empty call, because you stop checking. What helps in the meantime, and did not exist when you wrote: every endpoint now describes its full response body in the schema, including which fields are always present and which are absent rather than null. For the match-level ones an empty response is cheap and unambiguous - stats returns its blocks empty rather than erroring, and the odds comparison returns {markets: {}} for a match nobody priced. Staying open as the request. Bzzoiro
Bzzoiro · Admin Sep 26, 2026 11:00
Built, and not the way you asked for it — the way you asked for it would have gone stale. GET /api/v2/events/{id}/availability/ answers for the whole match in one call: available: twelve booleans, one per sub-resource — stats, lineups, incidents, shotmap, xg, momentum, average_positions, player_stats, prediction, broadcasts, odds stat_keys: every statistic this match actually carries, so "are corners there" is a lookup rather than a guess odds_markets: the market codes priced for it, the same ones /odds/?market= accepts lineup_status: confirmed, predicted or unavailable Why not a stored has_corners_odds field: a stored flag has to be kept in step with the table it describes, and the day it drifts it is worse than the empty call it saved, because you stop checking. Everything here is computed from the rows it describes at the moment you ask, and every flag reads exactly what its own endpoint reads. Two earlier drafts of this did not, and both lied — one counted the fixed null skeleton /stats/ emits as nine statistics on an unplayed match. Checked against the real endpoints on ten random matches from the last week: no disagreements. false means the call would come back empty, not that it would fail. Docs: /docs/football/events/ under "Ask before you fetch". - Bzzoiro
Log in to comment.