Irish horse racing API: racecards and results

For Irish coverage, the first decision is not which country code to pick, but which region context to use. RacingAPI.net uses region=uk to return both UK and Irish meetings. That means Irish racecards are part of the same daily feed as UK cards, so your application should not build separate request paths or separate assumptions about “Ireland” as an independent region.

In practice, this matters when you cache, filter and label meetings. A meeting returned from the combined feed may be Irish, but the request context is still the shared region. Keep the country identity on the meeting or course record itself, and present it in the UI from the returned data rather than inferring it from a different region parameter.

The racecards endpoint is the best starting point for Irish race-day coverage because it gives you the meeting date, course, race time, distance, going and runners. For display purposes, that is enough to build the top-level racecard page and the meeting navigation without forcing extra calls for every race in the list.

When you are building a racecard for Irish meetings, keep the identifiers stable all the way through the interface. The racecard feed gives you race-level IDs, and those should be used as the source of truth for drill-down pages, runner links and later result lookups. That avoids brittle matching on text labels such as course names or times.

The important integration point is the hand-off from a declared race to its final result. RacingAPI.net provides race details through /v1/races/{id} and results through /v1/results and /v1/results/{raceId}. That means the race ID should travel unchanged from the racecard screen to the results screen, even if the meeting is Irish and the page is being viewed inside a UK-wide calendar.

This is especially useful when the UI needs to show a race preview before the off and a result card afterwards. You can keep one canonical race record, then swap in the finishing positions, starting prices and result details once the result endpoint becomes available. The race identity stays the same; only the state changes.

Irish runners often need more than a basic card view, but it is important not to overstate what the connections endpoints provide. Horse form statistics, jockey connections and trainer connections are supplied in the selected daily feed context. They are useful for a race-day page, but they are not a complete career database and should not be presented as one.

For an Irish racecard, the best pattern is to show the meeting, then each race, then the runner-level context that belongs to that feed date. That lets users see declared runners, horse form summary, jockey bookings and trainer connections together without implying you have full historical depth for every competitor.

Irish race-day coverage is often consumed in a live interface, so your display layer should be built to reuse the same canonical API data rather than copying it into multiple incompatible views. The customer owns their own-site display use, but API resale, redistribution and sharing an account with other developers are not allowed. That means your system should be structured for internal product use, not for republishing the feed as a shared data service.

A good display design will also separate content from presentation. For example, keep meeting labels, race times, course names, runners and result records in one model, and let the UI decide how to group them. That makes it easier to show Irish and UK meetings together while still making the country context obvious to the user.

A clean race-day flow usually starts with the racecards feed, moves into race detail pages, and then switches to results as the meeting progresses. For Irish racing, the same flow works well because the combined region feed already includes the meeting alongside UK cards. You do not need a special branch in your architecture; you need a reliable mapping from the meeting list to race IDs and then to result records.

If you want a robust user experience, treat the racecard as the preview and the result as the final state of the same race. Preserve the course, distance and race time from the racecard, then add finishing positions and starting prices once the result arrives. That keeps the page coherent whether the user lands before the off or after the final result.