Race reports

A written account of every race, and the one line per runner behind it.

Every race in the archive from 2020 onwards carries a written report: a headline, how the race looked beforehand, what happened, and one line for every runner.

They are drawn entirely from the records this API already returns. Nothing in a report comes from anywhere the data does not go.

What a report contains

Field	What it is
`headline`	Eight words or fewer. Factual, not a headline in the tabloid sense.
`preview`	How the race looked an hour before it ran, using only what was knowable then. It never mentions the result.
`report`	What happened, leading with whatever made this race different from the others on the card.
`runners`	One sentence per horse, keyed by name. Each stands on its own without the report above it.

The per-runner lines are the part most people build with. They are what sits beside a horse on a results page.

What they will never say

No report describes how a race was run. There is no phrase about a horse travelling well, staying on, being outpaced or finding nothing, and none about where a faller fell.

That is deliberate, and it is a data limitation rather than a stylistic one. This archive holds no in-running positions, no sectional times, no video and no rider comment. A report that described any of those would be inventing them, and a plausible invention is worse than an omission because you cannot tell it apart from a fact.

Winning margins are absent for the same reason: beaten_distance is not published across this archive, so no report claims one.

What they do instead is tell you what the market thought and whether it was right. Every starting price implies a probability, and with the book margin stripped out that probability is a fair one. A report will tell you the winner was a 9.7% chance, or that the favourite was given 48.7% and finished fourth of five. That is checkable, and it is the part worth reading.

Getting them

Three ways, depending on what you are building.

With a race you are already fetching. Add include=report to the race endpoint and the report arrives in the same response. It is opt-in because it roughly doubles the size of the payload, and most callers want the data rather than the prose.

GET /v1/races/{race_id}?include=report

For a whole day. The same parameter on results by date attaches a report to every race on every card. Every report for the day is fetched in one query, so the cost does not grow with the number of meetings.

GET /v1/results/2024-03-16?include=report

On their own. Search reports by date, course or jurisdiction when the text is what you are after rather than the race data.

GET /v1/reports?from=2024-03-01&to=2024-03-31&course=Cheltenham

Coverage is partial

Reports begin in 2020 and cover Britain and Ireland. They do not exist for earlier races, and they do not exist for other jurisdictions, because the market movement that carries most of their substance is not published outside those two.

Report coverage returns the counts, the date range and the split by year, and it works on a free key. Whether the reports are worth paying for depends on how many there are and which years they cover, and that is not a question you should have to pay to answer.

A race with no report returns null rather than an error. A gap in partial coverage is not a fault.

Which plan

Complete and Complete + Analyst. The written pages on this site are public and free to read; the API delivery is not, because an endpoint hands over a bulk feed of the same text in a way a page does not.