Data API · Events

Live match analysis

GET/api/v1/datas/live-analysis/{id}

Returns the whole live analysis of one match as a single document: status and clock, teams, per-minute momentum, timeline, fifteen-minute dynamics, possession, lineups, per-player metrics, goals, discipline and attacking. The discipline section holds the referee indices of the match, each side's fouls, fouls won, cards and offsides with its aggression and discipline ratios, and every foul in order with its clock, the players involved and the card it drew. The attacking section holds each side's advanced attacking parameters - shot accuracy and conversion, possession effectiveness, intensity, control, chaos, tempo and directness - each as numerator, denominator and ratio. The numbers equal the advanced parameters of the legacy live endpoint, with the same raw and metrics fields as the advanced-parameters endpoint, and that parity is kept on purpose: the possession count follows the legacy convention and counts every possession marker, the one tagged where a possession starts and the one tagged where it ends, so it is roughly twice the possession count of the possession section. Every section is computed from the live tagging stream of this match, so the document is there while the match is still being tagged, and it is only ever as complete as the tagging is. Two things follow, and a broadcast client should plan around them rather than discover them: the pitch positions in lineups are the tagged starting slots replayed through substitutions and dismissals, not tracked or averaged positions; and the stream carries no event coordinates and no pass recipients, so there is no shot map, no heat map and no passing network here, and no body part or pitch zone behind a goal. The body is the document api-v1 GET /api/online/analysis/{matchId} computes, passed through field for field, so the two can never disagree. It is snake_case at the source: ask for case=snake_case to get it exactly as api-v1 published it, because the default camelCase also rewrites the data keys of the maps inside it (the dynamics bucket keys 0-15 and 30-45+ become 015 and 3045+, the possession duration buckets 0_10 and over_45 become 010 and over45). Poll it like this: keep the ETag of the last 200, send it back in If-None-Match, and expect 304 with an empty body for as long as nothing has changed. Cache-Control says how long the document is good for, five seconds while the match is live and three hundred seconds once it is not, and this endpoint allows 240 requests a minute for the token instead of the 60 the other Data API routes share - room for one match every five seconds, or several matches every fifteen. The published ETag is weak and is qualified by the representation that was asked for - the case and format, and the section selection of include and segments - for example W/"json.camelCase~la:v3:719279:1f902ecd821e", so a tag taken with one representation never matches a request made with another. The source API tags the match rather than the selection, so without that qualification a client holding the whole bundle would be answered 304 for a narrower include. Treat the tag as an opaque string and send it back exactly as it was received.

Reference only — this page never sends API requests or exposes token controls.