Horse racing results API: displaying race outcomes

For a results screen that feels complete, begin with the racecard feed and treat it as the structural source for the race. The racecard supplies the race ID, course, date, time, distance, going and declared runners. That lets you build the page shell before results are available, and it gives you a stable way to match each finisher back to a known runner.

This matters because the results feed is outcome-centric. It gives you finishing positions and related fields, but it is not a full page model for the race. If you start with results alone, you may end up with a list of finishers that lacks the declared runners who did not complete, were withdrawn, or were otherwise absent from the finishing order.

A practical approach is to load racecards by region and date, then fetch the individual race details when the user opens a race. Once results are available, join on race ID. That preserves the declared field and lets you display every runner consistently, whether the horse finished, was pulled up, fell, or is simply missing from the finishers list.

The result feed exposes race-level and runner-level outcome data. In the published fields, the race result endpoint returns finishers and wagers, while the broader results endpoint returns records with raceId, position, horseId, startingPrice, time and distance. That means your display logic should join on raceId first, then align each finisher with the declared runner list using horseId where present.

When a horse appears in both the racecard and the results feed, you can enrich the row with the runner name, number and other racecard attributes. If a result record includes horseId but your cached racecard entry is stale, refresh the racecard before rendering the final view. This avoids showing an outdated runner name or missing a late substitution.

Keep the join logic tolerant of partial matches. Some result records may be present before your local cache is refreshed, and some runner-level fields may be absent. Your interface should still display the position, starting price and any returned timing or distance information without requiring every racecard attribute to exist first.

Users reading a results page expect the official order to be obvious. Display the position field directly and avoid inventing secondary ranking rules from racecard order or bookmaker prices. If a result row contains a starting price, show it as returned. RacingAPI.net preserves source price strings, which is important because price format can vary and should not be normalised into a guessed decimal or fractional representation unless you do that explicitly in your own presentation layer.

Do not assume every runner will have the same supporting data. Some rows will include startingPrice, some may include time or distance, and some may omit fields depending on the available result details. A robust table shows the shared core first: finishing position, runner name, and starting price where present.

If you display price movement elsewhere on your site, keep the result price distinct from any live odds. The race odds feed reflects observed bookmaker prices in the live feed, while the results feed records the starting price associated with the completed race. Those are related facts, but they answer different questions.

A results screen should expect corrections. Race outcomes can be updated after the first version of the page is rendered, so your application should treat result records as mutable within a short operational window. The safest pattern is to refresh the race result endpoint when the user opens the page, and then refresh again on a sensible schedule while the event is still live or shortly after it finishes.

When a correction arrives, replace the affected race result record rather than appending a second version of the same finish. If your system stores history, keep an audit trail internally, but only the latest official outcome should drive the visible table. This keeps placings, non-runners, dead-heats or amended fields from being shown twice.

The important product boundary is that the results feed is the source of outcome data, not a settlement engine. If a correction changes a placing, your display updates because the result changed. You should not try to infer that update from a tip or from a bookmaker price change.

Not every race result arrives as a fully populated final table at the same moment. Some races may have finishers returned before all related details are present, and some result screens may be opened before the final official set is complete. Your interface should distinguish between a complete race result and a partial one instead of pretending both are the same.

A useful pattern is to render a status line based on what the endpoint returns. If finishers are present, show those positions immediately. If some runners from the racecard are not represented in the result set yet, leave them in the declared field section or show them as not yet placed, depending on your product design. That makes the page honest about what is known and what is still pending.

This is especially important for exported or cached views. If you store result snapshots, label them with the fetch time so users can tell whether they are looking at a near-live intermediate state or the final official result. That also helps support teams explain apparent mismatches between a racecard and a result page.

One of the most common implementation mistakes is to mix a race result with a tip outcome. On RacingAPI.net, tips are Enterprise-only live AI-assisted selections with saved explanations, and they are not the same thing as results. A tip tells you what was selected before the race; a result tells you what actually happened after the race.

If your product displays both, use different labels, data models and status states. A tip can be unresolved, selected, or explained. A result can be partial, final, or corrected. Settlement logic in your application should therefore read the race outcome first, then evaluate whether a stored tip would have won or placed according to your own rules.

That distinction matters for user trust. If you show a tip alongside a result, make it obvious that the selection was generated ahead of time and that the result is the official finish order. Never present a tip as if it were a verified outcome, and never use a result row to rewrite the tip history after the fact.