Horse racing racecards API: building a race-day page

For a race-day page, the safest starting point is the daily racecards feed for the UK and Ireland region. That feed gives you the meeting-level structure you need to build the page hierarchy: course, date, time, distance, going and the runners attached to each race. Because region=uk covers both countries, you only need one regional selector for the combined card.

Use the feed to render the landing view before any user interaction. A useful pattern is to group by course, then sort races by off-time, then present a compact summary for each race. That lets the page load quickly and gives the user a clear route to the information they actually want. The feed is enough for the overview, but it is not a substitute for race-specific or runner-specific detail when you need fuller data.

The biggest implementation mistake is to treat each runner as if its number were a stable identifier. In racecards, a runner number is a presentation value for the race, not a database key. Scratches, late declarations and field reshuffles can change how numbers appear while the underlying runner identity remains different. Build your UI data model around the race and the runner record returned by the API, not around the saddle cloth number alone.

When a user drills into a race, fetch the race detail endpoint for that race ID. That gives you the declared runners associated with that race and lets you keep the overview and the drill-down in sync. On the page, use the race object for the header and the runner objects for the list. If you need a horse-specific view, then use the horse endpoint or horse-form endpoint with the horse ID from the declared runner record, not the visible number from the race card.

A race-day page is most useful when it reflects what is declared now, not what was listed yesterday. RacingAPI.net racecard data is centred on declared runners, which makes it suitable for a live race-day view. If a runner is removed or the race composition changes, the updated feed should be the basis for what the user sees. Avoid storing stale copies in a way that leaves the page looking authoritative when it is not.

For the front end, the best pattern is to separate the race header from the runner status. If a runner is absent from the latest race detail, do not leave it in the visible list just because it appeared earlier in the session. If you keep cached data locally, make sure the current race detail replaces the old runner list rather than merging into it blindly. That matters especially on busy race days, where declarations can change after the page first loads.

Users scan racecards for a few core details before reading anything else: distance, going and the course itself. These should be visible in the meeting summary and repeated in the race detail header. The racecard feed includes the fields needed for that summary, so you can keep the design compact without forcing the user into the detail view for basic context.

Keep the presentation consistent across the meeting list and the race page. If the card shows distance in one format in the overview and another format in the detail view, it becomes harder to compare races quickly. The same applies to going. The feed gives you the official racecard context, and that should stay distinct from any weather data you choose to surface elsewhere. If you add course weather, treat it as separate forecast context rather than a replacement for official going.

A race-day page usually feels better when the initial load is light and deeper data appears only when requested. Load the meeting feed first, then request the individual race detail when a user expands or selects a race. That keeps the overview fast and avoids fetching horse-specific information for every runner before anyone has asked for it.

Once the user opens a runner, fetch the horse profile or horse form endpoint using the horse ID from the runner record. This is the point where you can show the runner’s name, rating or supplied form summary if available in the daily feed. Keep the data boundary clear: race detail for the race, horse profile for the horse, horse form for the contextual daily summary. That separation makes the page easier to cache, easier to test and easier to debug when a field changes.

Race-day pages are read-heavy, so it makes sense to cache deliberately. Store the meeting feed and race detail responses long enough to reduce repeat requests, but do not let shared caches leak one user’s personalised view into another user’s session. Public racecard content can be reused safely when it is genuinely the same for everyone, but any page state that depends on a user’s selections should stay out of shared caching.

Plan for incremental refresh rather than constant polling. RacingAPI.net plans have clear request quotas and per-second limits, and those limits apply across keys on the account. If a request returns a rate-limit response, respect the Retry-After header rather than hammering the endpoint. That keeps the race-day page predictable during busy periods and prevents unnecessary retries when the feed is already under load from your own interface.