UK horse racing API: a developer’s guide

The centre of a race-day view is the daily feed. Use the racecards endpoint to discover the meetings and declared runners that are available for the selected region and date, then let the feed drive everything else on the page. That approach avoids stale fixtures, missed non-runners, and awkward special cases when an added meeting appears later in the day.

For a British race-day interface, the practical pattern is to load the region=uk racecards feed first, then group the returned meetings into a user-facing order such as course, race time or race status. The response gives you the core fields you need for a summary card: meeting identity, course, date, time, distance, going and runners.

A strong race-day page usually has two levels: the meeting and the race. The racecards feed can give you the overview, but race details are better rendered from the race-specific endpoint once the user opens a meeting or selects an individual contest. That separation keeps the list page light and lets the detail page carry fuller context without clutter.

The race details endpoint is useful when you want to show the race name, class, purse, distance and declared runners for a single race ID. It is the cleaner choice for detail drawers, race tabs or mobile drill-downs, where the user expects to move from the meeting summary to a focused race view.

Your race-day display should be careful about what the API does and does not claim. The documented feeds provide declared runners and race context, but they do not promise a complete career database or every historical change. Build around the current daily feed and label the information as declared or available in the selected feed.

If a runner appears in the racecards feed, show it as declared for that race. If your product needs a later non-runner indicator, you should not manufacture it from outside assumptions. Instead, refresh the racecards and race detail endpoints at sensible intervals and let the returned feed represent the latest known state. That keeps the UI consistent with the actual data contract.

Once the user clicks a runner, the horse search and horse profile endpoints are the most direct way to add context. Horse search is designed for declared runners in the selected regional daily feed, so it is suitable for resolving the runner into the correct horse ID without treating it as a complete database of every horse ever raced.

From the horse profile, you can show the basics that help a race-day user make sense of the card: identity, age, gender, rating and form. Keep the copy precise. The form data is available within the selected daily feed, so it should be presented as current context, not as a full career timeline.

Trainer and jockey data works best as supporting context, not as a replacement for the racecard. The connections endpoints are useful when you want to show bookings and horse-specific connections within the selected daily feed. That makes them a good fit for a compact race-day sidebar, runner drawer or tooltip.

Because these endpoints are scoped to the daily feed, your wording should stay equally scoped. Use phrasing such as “declared runner connections” or “within today’s feed” rather than broad claims about career records. That keeps the page accurate and prevents users from assuming they are looking at full historical trainer or jockey statistics.

A race-day view should not stop at the off-time. Once races finish, the results endpoints let you turn the same meeting experience into a results page without changing your navigation structure. The results feed provides finishing positions, starting prices and available result details, while the race result endpoint is helpful when you want the full result record for a specific race.

This is the point where a clean state model matters. Keep your scheduled race cards visible where appropriate, but mark completed races clearly and move their detail pane over to the result payload. That gives the user a seamless transition from preview to outcome without forcing them into a separate section of the site.

Course weather can add useful context to the race-day screen, especially when you want to explain how conditions may feel at the track. RacingAPI.net supplies course-location weather forecasts with temperature, rainfall, wind and humidity, and the forecast is separate from official going. That distinction matters, so keep the source attribution visible and do not merge forecast weather into the going field.

Odds can also be layered into the race view, but the odds endpoint should be displayed exactly as observed. Preserve the bookmaker, price string and timestamped context you receive, and avoid implying universal bookmaker coverage or a guaranteed refresh cadence. The safest presentation is to show the market snapshot beside the racecard, not as a complete or definitive book.