Horse Racing Results API

This endpoint lists races that have non-empty finishers in the selected feed. It is not a predictive finish-order service and it does not return speculative outcomes. If a race appears here, it means the feed has published results for that race day and there is something meaningful to show in your archive, settlement page or post-event content flow. Where the source provides wagers, those are included with the list item.

The list is built around race records, not runner-level pagination. Each race item includes its nested runners, so one request can support a page of completed races without forcing you to call a separate endpoint for every runner. If you need the detailed record for a single race, the natural follow-up is the individual result endpoint at /v1/results/{raceId}, using the race ID supplied in the list response.

The primary control for this endpoint is date. You can request a specific calendar day in YYYY-MM-DD format and build a results archive page that matches the user’s chosen date. There is also a documented tomorrow feed, which is separate from date and cannot be combined with it. That gives you a clean way to support forward-looking pages where your product needs to pre-load the next day’s feed context.

Historical depth is available in the combined UK and Ireland archive, with explicit UK archive dates sampled back to 2016. That is useful for archive browsing, but it should be treated as a feed-based history rather than a promise that every date is complete. In practice, this means your interface should handle sparse or empty days gracefully and present the selected date as the user’s chosen feed view, not as a guaranteed full historical dataset.

A common implementation is a date-first archive. Your frontend can offer a calendar picker, then load the selected day through this endpoint and display only the races with published finishers. Because the response is already filtered to completed results, the page can be framed as a live archive rather than a mixed racecard/results view. This is especially helpful for public results pages where users expect completed races only.

You can also build pagination into the archive experience using page and limit. The list is one-based, so page 1 is the first slice of the selected day and later pages progressively reveal more race items. If the user goes beyond the last page, the data comes back empty while meta.total still reflects the total number of items before pagination. That makes it straightforward to show a stable results count and retain the selected date in your interface.

The real value of this endpoint is in the ID flow. IDs come from the feed, not from name matching, so you can build a reliable join between the race list and your detailed result pages. The list gives you the race identifier, and that same ID can be passed into /v1/results/{raceId} when you need the full race result record. This avoids brittle matching on race names, courses or meeting labels.

For product teams, that means less reconciliation logic and fewer edge cases when a day contains multiple similar race names or changing presentation labels. The list endpoint is ideal for discovery and navigation, while the single-race result endpoint is the record you open after the user clicks through. In other words, /v1/results helps people find the right result, and /v1/results/{raceId} shows them the detailed page they expected to open.

Many customers use this endpoint to power a results centre with filters for date, a compact list of completed races, and click-through detail pages. Others use it as a settlement back-end for internal teams who need to confirm what has finished on a given day before publishing summaries, reconciliation notes or historical browsing tools. Because the feed only shows races with published finishers, it keeps the UI focused on completed events rather than live racecard content.

If you are building a newsroom or content workflow, the endpoint can act as the trigger for post-race updates. Editors can open the selected day, find the race IDs, and use those IDs to pull the richer result record for each race. That supports a structured editorial process without relying on manual copying from a page or on users searching by race title alone.

This is a daily-feed results view, so the surrounding profile and statistics context elsewhere in the platform should be understood in the same daily-feed way. The endpoint is for published race results, not a universal lifetime archive of every horse, jockey or trainer record. If your product needs deep profile context, that belongs in the relevant profile or form endpoints rather than here. The results feed is about what has been published for the selected day.

Where source-supplied wagers exist, they are part of the list response, which can be useful for results presentation and summary pages. The endpoint does not invent or infer data that is not in the feed. If a day has no published results, the correct state is an empty list. That behaviour is useful in production because it lets your app distinguish between no results and no response, instead of treating a quiet day as an error.

A straightforward implementation begins with authentication on your server, where your API key stays under your control. Your application then requests /v1/results with region=uk and either a date or tomorrow, depending on the page you are building. From there, you render the list, store or cache the race IDs as needed, and route users into /v1/results/{raceId} for deeper detail. Because the list and single-record lookup are distinct products, the workflow stays simple and predictable.

In a typical front end, you would expose a date selector, a pagination control and a results table or card list. On the back end, you would validate the selected day, manage request volume against your plan limits and handle empty responses as a normal state. If you are building a larger archive, keep the selected date in the URL so pages can be shared and revisited without confusion. That gives you a clean, commercial results feature rather than a one-off API demo.