Individual Race Result API

This endpoint is built for one known race, which is why it sits alongside the collection results feed rather than replacing it. The collection endpoint is for discovering races and building lists; this one is for drilling into a single published result page once the raceId is already in hand. That split matters in product design because it lets you keep list browsing and detail retrieval separate, with different error handling and page states.

A common integration pattern is to fetch racecards or a race list first, store the race ID from the feed, then call /v1/results/{raceId} when the user opens the result screen. Because IDs come from the feed, you should not try to reconstruct them from names or venue labels. That keeps the lookup aligned with the published record and avoids mismatches when meetings contain similar runner names or repeated race titles.

The response is intended to give you the essentials for a clean finishers table. You can show the finishing order as supplied, the horse identifiers from the feed, and starting prices where those are included for the race. That is enough to build a clear result panel with ranked finishers, a straightforward winner highlight and any supporting data that your front end already displays from the racecard or horse profile endpoints.

If your product shows race outcomes next to the original card, this endpoint lets you keep the page compact and unambiguous. The data belongs to the daily-feed context, so horse, jockey and trainer references should be treated as contextual profiles and statistics for the feed day, not as a guarantee of universal career-history coverage. That distinction is important if you also display links to form, connections or racecourse information.

The query options are deliberately limited so the result matches the feed you intended to read. region=uk is the only accepted region value, and it represents the combined UK and Ireland feed. There is no separate Ireland region code for customer access. You can also choose a specific YYYY-MM-DD date when you need the archived feed context, or use tomorrow=true for the documented tomorrow feed. Date and tomorrow cannot be combined.

This makes the endpoint practical for scheduled publishing workflows. For example, a newsroom or racecentre page can request a date-specific result after a meeting has been run, while a preview page can use tomorrow=true to keep a future race card and its eventual result slot aligned with the same race ID once it is published. Continuous archive completeness is not guaranteed, so your UI should handle the absence of a published result cleanly.

A typical build starts with the racecards or race details endpoint, where you obtain the raceId for the meeting and keep it in your application state. When the user clicks through to the result view, call GET /v1/results/{raceId} with the same region context, and add date or tomorrow only when your page is intentionally tied to a specific feed day. That gives you a stable, feed-driven path from discovery to display.

Because result pages are often opened repeatedly, many teams cache their own rendered page state rather than re-creating the race identity from scratch. Keys stay on the customer’s server, so the server-side component can handle authentication and response shaping before the front end renders the table. This is also the place to translate API error codes into user-facing messages such as ‘result not yet published’ or ‘race not found in this feed’.

The endpoint is best presented as a table with columns that match the meaning of the response, not as a generic card list. Preserve the positions as supplied by the feed, because the order is part of the published result rather than something your application should infer. Where starting prices are present, display them exactly as returned so the result row stays consistent with the race record and any later reporting on the same page.

Horse identifiers should remain the primary link target in your own system if you want to connect the result row to horse profiles, form statistics or connections data. That is safer than relying on text labels alone, because the feed ID is the durable key. If your product uses silks, remember that the silks endpoint returns PNG owner colours, not portraits, so the result page can pair the horse row with the correct visual without implying an image of the animal or person.

A strong race detail page usually combines several RacingAPI.net services. The racecards feed provides the pre-race structure, this endpoint supplies the published outcome, and the odds feed can show bookmaker prices for the race where available. If you also include racecourse weather, remember that MET Norway forecasts are separate from official going and carry their own attribution and expiry. Each feed has a different job, and keeping them separate helps the page remain accurate.

The result endpoint itself does not try to invent missing context from other services. It returns finishers and wagers for the selected race only, so if a race has no published finishers yet, you get a 404 rather than a placeholder result. That makes state handling easier: pre-race pages, live pages and settled result pages can each show the right message based on the feed response instead of guessing.

This endpoint is included on all active plans, so it is available whether you are building a small editorial site or a larger results platform. Plan choice then comes down to request volume and throughput: Developer is £29/month for 10,000 monthly requests at 2 requests/second, Professional is £79/month for 100,000 at 5 requests/second, and Enterprise is £99.99/month with unlimited monthly requests at 10 requests/second. VAT is not added.

Monthly quotas reset on the first UTC calendar day of each month. Access becomes active after on-site checkout is confirmed, and eligible new customers can receive one seven-day trial after checkout with a card; sign-up alone does not begin a trial. Subscriptions, cards and invoices remain on-site, which keeps account administration separate from the API integration itself. Keys stay on the customer’s server, and resale, onward API access and account sharing are not permitted.