Horse Racing Data API or Dataset: Which Fits?

You are evaluating a horse racing data API against a historical dataset. Both come from the same source. They suit different jobs.

This guide helps you choose. It covers what each option gives you, how quotas work, and what to check before you buy.

What HRDB offers

There are three ways to work with our data:

• Historical datasets in CSV, SQL and JSON.
• A REST API with stable identifiers and per-plan usage limits.
• Bespoke exports and enterprise support for needs that do not fit a standard plan.

The underlying coverage is the same whichever you choose: 2.2M result records, 226K races, 173K horses and 85+ racecourses across the United Kingdom, Ireland and Hong Kong. Hong Kong history starts in 1979. UK and Ireland history starts in 2011. Sectional times are available for Hong Kong from 2008 and for the UK from 2017.

When a dataset is the better fit

Choose a dataset when your main task is bulk work on history. Typical cases:

• Training a model on many seasons at once.
• Backtesting a method against a fixed historical window.
• Loading everything into your own warehouse and querying it with SQL.

A dataset gives you the full history in a format you already use. There are no per-call limits to plan around. You decide the format (CSV, SQL or JSON) and keep working from your own copy.

The trade-off is freshness. A dataset is a snapshot. If you need new results as they are added, you will need a second route for that.

When the API is the better fit

Choose the API when your product needs data to stay current. Typical cases:

• A production pipeline that ingests new results each day.
• A tipster product that publishes racecards for its own markets.
• A trainer or jockey dashboard that reads from stable IDs.

The public documentation lists 26 UK and 30 Hong Kong data endpoints. They cover races, racecards, records (results), horses, jockeys, trainers and courses. Hong Kong also has veterinary records. UK and Hong Kong data live in separate, isolated schemas, so one market cannot contaminate the other.

Access is simple. You exchange an API key for a token valid for 24 hours with POST /auth/token. You can then check your quota at any time with GET /user/usage. That call reports quota used and remaining, and it does not consume a call.

Be clear about what daily means

This is a daily, after-racing data source. Racecards and results are updated daily. It is not a live or real-time feed, and there are no webhooks.

If your design needs in-race updates, we are not the right source. If your design needs reliable data each day, with the previous day’s racing complete and checked, we are.

Every nightly update passes automated integrity gates before it is published:

• No horse assigned to two races on the same day.
• No duplicate runner rows.
• No missing horse, jockey or trainer IDs.
• Separation of different horses that share a name.

For a production team, this matters more than any single feature. It is what keeps your joins clean.

Sizing your volume with a real day

The easiest way to size a plan is to look at one day. One recent day’s racecard signal shows:

• UK and Ireland: 47 races and 536 runners across Chepstow, Dundalk, Kempton, Musselburgh, Nottingham and Wexford.
• Hong Kong: 9 races and 108 runners at Happy Valley.

That is 56 races and 644 runners on one day across both regions. It is a single day, not an average, and busy days will differ. But it shows the shape of a daily pull.

Then ask how your system would fetch it. One call per race is very different from one call per course or per day. Your answer sets the volume you need.

Quotas and add-on packs

Each plan has its own usage quota. If you exceed it, add-on packs provide extra calls. You do not need to move to a bigger plan for one heavy month.

A sensible approach:

1. Estimate your daily calls from a sample day like the one above.
2. Add the calls for any historical backfill you plan to run through the API.
3. Choose the plan that covers your normal month.
4. Treat add-on packs as your buffer for spikes.

API access is provisioned automatically after purchase. You do not wait for a manual set-up.

Prices change, so we do not quote them here. The plans page always shows the current options.

Many teams use both

The two options work well together. A common pattern is:

• Load the dataset once for deep history and model training.
• Use the API for the daily increment.

Because identifiers are stable, records from both routes join without remapping. That is the point of stable IDs.

Questions to settle before you buy

Use this short list with your team:

• Do we need history, daily updates, or both?
• Which regions do we need: UK and Ireland, Hong Kong, or both?
• Do our models depend on sectionals? If so, check the start years above against your training window.
• How many calls will a normal day need?
• Do we need a bespoke export or enterprise support?

US, Canadian, Pacific and global racing are on the roadmap, not currently available. Plan only around the coverage listed here.

If your answers point to a standard plan, pick one from the plans page. If they do not, a bespoke export is the next step.

Next step: Explore the datasets