Premier League Injuries & Availability

Every Premier League player who is injured, doubtful, suspended or otherwise unavailable — with the official status note, the percentage chance of playing the next round, and the date that note was posted.

One run covers all 20 clubs. No API key, no login, no club pages to scrape.

{
  "webName": "Bruno G.",
  "name": "Bruno Guimarães",
  "team": "Newcastle United",
  "teamShort": "NEW",
  "position": "Midfielder",
  "status": "d",
  "statusLabel": "doubtful",
  "kind": "injury",
  "chanceOfPlayingNextRound": 75,
  "reason": "Thigh injury",
  "detail": "75% chance of playing",
  "expectedReturn": null,
  "news": "Thigh injury - 75% chance of playing",
  "newsAdded": "2026-08-20T17:30:22.531453Z",
  "daysSinceNews": 6,
  "price": 6.5,
  "source": "Official Fantasy Premier League API"
}

Where the data comes from

The Premier League's own Fantasy Premier League feed. It is the league's public availability data: one status per player, a percentage chance of playing the next round, and a short note in plain English, updated by the game's editorial team as news breaks.

That matters for three reasons:

• It is the club's position, not a rumour. The note is what the league published, not an aggregation of press speculation.
• It is stable. No key, no rate-limit tier, no login, no headless browser. One request serves the whole league, so scheduled runs do not quietly break.
• It is timestamped. newsAdded tells you when the status last moved, so a stale note is visible as stale instead of reading like today's news.

This Actor is not affiliated with, endorsed by, or connected to the Premier League or Fantasy Premier League. It reads a public endpoint and reshapes it; all data belongs to its publisher.

What you can ask for

Option	What it does
Clubs	Club names or three-letter codes — Arsenal, MCI, Newcastle. Empty means all 20.
Statuses	Injured, doubtful, suspended, unavailable, not in squad, available. Empty means everyone with something to report.
Kind of absence	Injury, suspension, transfer or loan, personal, unclassified.
Include fully fit players	Off by default. On, you get all ~600 players as a squad snapshot.
Minimum / maximum chance of playing	Set both to isolate the genuinely doubtful, e.g. 25–75.
Maximum rows	0 for no cap. A whole-league run is roughly 100–150 rows.
Monitor mode	Only what changed since the last run. See below.

The filter rule worth knowing

A filter that cannot be evaluated excludes the row. If you set a minimum chance of playing and the league has not published a chance for a given player, that player is left out rather than let through. The alternative — treating "no value" as "nothing to object to" — delivers rows that were checked against nothing, and you would be paying for them.

Injuries, not transfers

The league files a sold player and a torn hamstring under the same status code. This Actor separates them: pick Injury under Kind of absence and the winger who joined another club last week stays out of your results.

Monitor mode — only what changed

Turn on Monitor mode and each run compares against the previous one, returning only movement:

Change	Meaning
new_absence	A fit player is now injured, doubtful or suspended
returned	A player who was unavailable is available again
status_changed	Injured → doubtful, doubtful → suspended, and so on
chance_changed	The percentage chance of playing moved, e.g. 25% → 75%
news_updated	Same status, rewritten note — often the first sign of a return date

Each change row carries previousStatus, previousStatusChance and previousNews, so you can see what it moved from without keeping your own history.

The first monitor run records a baseline and charges nothing. Reporting the entire league as "newly injured" the first time would be a bill for news that is not news. Run it on a schedule — hourly or daily — and every run after the first returns only what moved.

Memory lives in a named key-value store (Monitor memory store, default pl-availability-state). Use different names to watch different filters independently; turn on Reset the monitor memory to start a fresh baseline.

Output fields

Field	Notes
playerId, playerCode	Stable ids for joining across runs
name, webName	Full name and the short form used in tables
team, teamShort, teamId	Club
position, positionShort	Goalkeeper / Defender / Midfielder / Forward
status, statusLabel	The league's code and its meaning
kind	injury · suspension · transfer · personal · unknown
chanceOfPlayingNextRound	0–100, or null when unpublished
chanceOfPlayingThisRound	Same for the current round
reason, detail	The note, split at the dash: "Thigh injury" / "75% chance of playing"
expectedReturn	YYYY-MM-DD, only when the note actually names a date
news, newsAdded, daysSinceNews	The raw note, when it was posted, and how old it is
price, selectedByPercent, minutes, totalPoints	Fantasy price, ownership and season form
source, sourceUrl, scrapedAt	Provenance for every row
changeType, previousStatus, previousStatusChance, previousNews, detectedAt	Monitor mode only

About expectedReturn

The league writes return dates as "Expected back 12 Sep" — day and month, never a year. This Actor resolves that to the next occurrence at or after the run date and returns null whenever the note names no date at all. A guessed date is worse than none: you can act on "unknown", and you cannot act on a wrong Tuesday.

Pricing

Pay per event — you are charged for rows delivered, never for a failed run.

Event	Price
Availability row	$0.20 per 1,000
Availability change reported (monitor mode)	$0.40 per 1,000

A whole-league snapshot is around 100–150 rows, so a full run costs about three hundredths of a cent. A daily monitor typically reports a handful of changes a day.

Rows are billed after they are written to your dataset. If a run stops at your Max total charge, it says so in the log rather than silently truncating.

What this does not do

Stated plainly, so you can decide before you run it:

• Premier League only. The feed covers the English top flight. No La Liga, Serie A, Bundesliga or Ligue 1.
• No expected return date for most players. The league publishes one when a club has given one; otherwise the note says "Unknown return date" and this Actor returns null rather than inventing an estimate.
• No injury history. Rows describe the current state, and monitor mode gives you the transitions from the moment you start watching. There is no backfill of past seasons.
• No medical detail. "Groin injury" is what is published; grade, scan results and treatment are not.

Suggested uses

• Fantasy and prediction tools — availability is the input that changes lineups, and chanceOfPlayingNextRound is a number you can model with directly.
• Team-news alerts — monitor mode into Slack, Discord or a webhook, so a status flip reaches you within the hour.
• Betting and trading models — an absence detected before it is widely priced is the whole value; newsAdded tells you how fresh the signal is.
• Sports media — a maintained injury table without maintaining a scraper.
• Squad planning and scouting — combine the availability flag with minutes and totalPoints to see who is actually being relied on.

Run it from code

Nothing here needs a login to the source, only your Apify token.

HTTP — start a run and wait for the rows:

curl -X POST "https://api.apify.com/v2/acts/gganbukim~premier-league-injury-scraper/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "content-type: application/json" \
  -d @input.json

JavaScript

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('gganbukim/premier-league-injury-scraper').call(input);
const { items } = await client.dataset(run.defaultDatasetId).listItems();

Python

from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("gganbukim/premier-league-injury-scraper").call(run_input=input)
items = client.dataset(run["defaultDatasetId"]).list_items().items

Scheduled or event-driven — attach a schedule to run it on a cron, or a webhook to push each finished run into your own endpoint. It also connects through Apify's Zapier, Make, n8n and LangChain integrations, and is reachable from an MCP server if you are driving it from an agent.

Standby / API mode — the run above is synchronous: one call in, rows out, no polling. That is the shape to use if you are calling this per request rather than in a batch.

Errors, limits and what you are charged for

• You pay for delivered rows only. A row your filters removed, a page that failed, a retry — none of it is billed. Starting a run costs $0.00001: the platform minimum, charged once per gigabyte, and this Actor runs on 512 MB.
• A run that delivers nothing still costs the start fee and nothing else. If the input resolved to zero items, the run fails loudly with the reason rather than finishing green on an empty dataset.
• Blocking is handled by changing address, not by waiting. The Actor starts on cheap datacenter proxies and moves up only after a tier has actually been refused several times in a row, then drops back down once the cheap tier answers cleanly again. You are not paying for residential bandwidth that was never needed.
• Rate limits belong to the source, not to this Actor. Very large inputs are worked through in batches; the run reports how many items succeeded, were filtered, and failed, so a partial result is never presented as a complete one.
• Dataset retention follows your Apify plan. Export what you need, or push it out with a webhook, if you want it past that window.

Is this legal?

This Actor reads pages and public endpoints that anyone can open in a browser without an account. It does not log in, does not defeat a paywall, and does not touch anything behind authentication.

Scraping public data is broadly lawful in the US and the EU, and courts have repeatedly said so — but "public" is not the same as "unrestricted", and what you may then do with the data is a separate question from whether you may collect it. Personal data pulls in the GDPR and similar regimes whatever the source, so if your rows contain people, you need a lawful basis for keeping them.

Apify publishes a fuller treatment in Is web scraping legal? and an ethical scraping guide. None of this is legal advice; if the use is commercial and the data is personal, ask someone qualified.

Something wrong, or missing?

Open an issue on the Actor's Issues tab — it goes straight to the developer and is the fastest route. Include the run ID; it carries the input and the log, which is usually enough to reproduce the problem without another round trip.

Sources change without warning, and a field that quietly goes null is worth reporting even if the run succeeded. A broken parser looks exactly like a quiet day in the data until someone says so.