Picking a horse racing data provider is a decision you live with for years. The data goes into models, products and reports, and by the time a problem shows up you have built a lot on top of it. Most buying guides list features. This one lists questions, because the features are the easy part and the questions are where providers differ.
Each question comes with a way to check the answer yourself. Ask for a sample file and the afternoon you spend testing it will tell you more than any brochure.
1. Which markets and which years, exactly?
“UK and Hong Kong” is not an answer. Ask for the first date in each market, the number of races per year, and any gaps. In our archive the UK and Ireland start on 2 January 2011 with 197,526 races, and Hong Kong on 22 September 1979 with 30,112. A quick check: count races per year and look for dips you cannot explain. (Ours has one, 2020, when racing stopped for the pandemic.)
2. How complete is each field, not each race?
A race can be present and half of its columns empty. Timing is the usual culprit. In our UK data, sectional times reach about 91% of British runners from 2024, but only 18% in 2017, and none for Irish racing. A provider who says “we have sectionals” without a coverage table by year and course has not measured it. Try this: group each column’s null rate by year.
3. Is a horse ID one horse?
Ask how identity is resolved. If the answer involves matching on name, be wary. Names repeat, and two horses called the same thing will merge into one history. To check: take the ten most common horse names and count the distinct IDs behind each.
4. What stops bad data going out?
Every dataset has errors. What matters is whether anything looks for them. Ask what checks run before a file is published. Ours stop an update if a horse is in two races on the same day, if a runner is duplicated, if a jockey or trainer ID is missing, or if two horses have been merged. Run those same checks on a sample yourself. It takes about ten lines of code.
5. When does the data arrive, and how?
Be precise about what “live” means. Our racecards and results are updated once a day, after racing. We do not offer a real-time feed, and we say so. If you need prices in the second before the off, you need a different kind of provider, and it is better to know that now. Note when a day’s results first appear, and compare it with what you were promised.
6. What does the schema look like, and does it change?
You want a documented data dictionary and a stable set of field names across years. Free scrapes of public results tend to change shape whenever the source site does. Load two years a decade apart and see whether the same code works on both.
7. What can you do with it legally?
Read the terms. Ask whether commercial use is allowed, whether you can redistribute derived products, and whether any of the content comes from a third party with its own rights. Some fields in racing data do. Ask for the licence in writing before you build, and ask the same question about every text field.
8. How do you get the history?
There are two models: bulk files and metered API calls. Bulk is cheaper for a full backfill. An API is better for daily updates and lookups. Many teams use both, loading the history once and then staying current through the API. Work out how many calls a full backfill would cost, then price it.
9. Who answers when something is wrong?
Ask for a support route, a response time and, if you can, how past incidents were handled. A provider who has never had one has not looked hard. Send a real question before you sign and see how long a useful answer takes.
10. What does it not do?
The most telling answer of the ten. We carry UK, Irish and Hong Kong racing only. Irish racing has no sectional times. There is no live feed. Hong Kong has veterinary records and dividends, and the UK does not. A provider that has no limits to describe is not describing them.
A short scorecard
| Question | What good looks like |
|---|---|
| Coverage | First dates stated, races per year, gaps explained |
| Field completeness | Null rate by year and course |
| Identity | Stable IDs, not name matching |
| Quality checks | Named checks that stop a release |
| Timing | Clear update schedule |
| Schema | Documented, stable |
| Licence | In writing |
| Access | Bulk and API |
| Support | Real answers, quickly |
| Limits | Stated without being asked |
No provider scores ten out of ten, including us. Pick the one whose gaps you can live with and whose answers you can verify. To run this on our data, start with the horse racing datasets and the API. The dataset checklist has the audit code, the data model shows how the tables fit, and the UK overview describes the coverage.
Comments are closed