Reported availability, nothing more
The injuries feed returns injury information the source supplies across the competitions your account can see. It takes no parameters and is cached for about fifteen minutes. Responses use the standard envelope: data with the source structure as supplied, and meta with the feed, UTC fetch time, cache time and qualification. Identifiers are strings and source attributes keep any at-sign prefix.
It is worth being exact about what that information is. It is a report, from the source, that a player is injured or otherwise unavailable, possibly with some description. It is not a medical record, a diagnosis, a statement from the club's medical staff or a forecast of when the player will return. Nothing in this feed, and nothing on this page, is medical advice.
Writing about injuries with care
Injury information concerns a real person's body. Present it plainly and avoid embellishment. If the source supplies a description, show it as supplied, attributed to the data rather than stated as fact in your own voice. Avoid speculative adjectives such as serious or minor unless the source uses them. Avoid estimating a return date unless one is supplied, and if one is, present it as reported rather than certain.
Readers do not need drama to make decisions. A fantasy manager wants to know whether a player is reported unavailable and when that information was checked. A journalist wants a starting point for their own reporting. Neither is served by an interface that turns a line of data into a headline.
- Show supplied wording, attributed to the data.
- Do not infer severity, diagnosis or recovery time.
- Display when the information was last checked.
- Remove reports promptly when they no longer appear.
Absence is not fitness
A player not appearing in the injuries feed does not mean the player is fit. The source may not have recorded an injury, may not cover that competition's injury news at all, or may update after the club announces something. Never present the absence of a report as confirmation of availability.
Design for this explicitly. On a preview page, the injury section should read as reported injuries and absences, not as a fitness list. If a competition you cover never seems to have injury reports, consider hiding the section for that competition and saying injury information is not available, rather than implying every player is healthy.
Joining reports to squads
The useful thing to do with an injury report is attach it to a player you already know about. The example fetches the feed, then joins reports to your stored squads on the player identifier. Reports for players you do not hold are kept aside for review rather than discarded, because they may indicate a squad change you have not picked up yet.
Store each report with the time you first saw it and the time you last saw it. When a report disappears from the feed, record that too. That history lets your interface show newly reported and no longer listed changes accurately.
import os, requests
r = requests.get(
"https://footballapi.net/api/v1/football/injuries",
headers={"X-API-Key": os.environ["FOOTBALLAPI_KEY"]},
timeout=30,
)
body = r.json()
r.raise_for_status()
for report in read_reports(body["data"]): # your mapping, written from a saved sample
pid = player_id_of(report) # mapping helper returns a string ID
if known_player(pid):
upsert_report(pid, report, body["meta"]["fetchedAt"])
else:
queue_for_review(pid, report)How often to check
Injury news clusters around press conferences and the day before a match. Refreshing every half hour on those days, and a few times a day otherwise, keeps a preview page current without spending requests on unchanged bodies. Polling faster than the fifteen-minute cache gives you the same response twice.
Because the feed covers many competitions in one response, a single scheduled job can serve every preview page you publish. Read from your stored copy on page load.
Injuries in fantasy tools
Fantasy tools are the heaviest users of injury information, and the stakes there are a manager's weekly decision. Show the report and the time it was checked next to the player, and make it easy to see when a report is new. Do not automatically bench or transfer a player on the user's behalf because a report appeared; give the user the information and the decision.
If your tool shows a status such as doubtful, make sure that word comes from the source rather than from your own interpretation of a description. If it is your interpretation, label it as such.
Privacy and tone
Even when injury information is publicly reported, it is personal. Do not combine it with other data to speculate about a player's long-term health, and do not build features that rank players by injury history in a way that invites ridicule. Use it for what it is for: helping readers understand who is reported as unavailable for upcoming matches.
If a player or club asks you to correct or remove something you published, take it seriously and contact support if you believe the underlying data is wrong.
Injury sections in match previews
A preview typically shows reported absences for both teams side by side. Build it from your stored reports joined to each team's squad by player identifier, ordered in a stable way such as by squad number or name, and headed reported absences. Show the time the information was last checked. If neither team has any reports, say that no injuries are reported in the data rather than declaring both squads fully fit.
Place the injury section near predicted line-ups if you show them, and make clear that both are reported or predicted information rather than confirmed team news. Readers should be able to tell at a glance what the club has announced and what comes from data.
Report lifecycle in your storage
Reports appear, persist for a while and disappear. Your storage should mirror that without guessing at reasons. Record when a report was first seen and last seen, and mark it no longer listed when it drops out. Do not convert a disappearance into a returned-to-fitness message; the report may have been removed for other reasons, and the player may still be unavailable.
Errors and outages
If a refresh fails with a 502 or 504, keep showing your stored reports with their last-checked time rather than clearing the section. Clearing it would wrongly suggest nobody is injured. Retry later with backoff and log the requestId from the error body so support can trace it.
Plan scope
The injuries feed is a global service that is not included in Starter. It requires Growth at EUR 99 a month or Pro at EUR 249, plus activation of the service for your account. A Starter key receives a 403 response with the subscription_required code, which is not billed.
Refreshing every half hour for a full day is 48 successful requests, small against the Growth inclusion of 25,000 per UTC day. Requests above the inclusion cost EUR 0.002 each on the monthly EUR invoice. There is no free trial, and no VAT is currently charged.
Questions developers ask
- Is injury data medical advice?
- No. It is reported availability information from the source, not a diagnosis, prognosis or medical statement.
- Does no injury report mean a player is fit?
- No. Absence of a report is not confirmation of fitness. The source may not have recorded or covered it.
- Does the feed give return dates?
- Only if the source supplies one, and then it should be shown as reported, not certain. Do not estimate return dates yourself.
- Does injuries take parameters?
- No. One request returns reports across the competitions your account can see.
- Is the injuries feed on Starter?
- No. It requires Growth or Pro and separate service activation.
Guides and documentation
Check the plan before you write the integration.
Starter EUR 29, Growth EUR 99, Pro EUR 249 per month. No free trial. No VAT currently charged.