Single Race Tip API

This endpoint answers one question: what is the saved tip for this race ID on the chosen date? When a qualifying selection exists, the response is the active race analysis for that racecard ID, including the selection itself, the saved odds and the bet type. It also carries the saved two-sentence explanation, so your interface can display the reasoning exactly as prepared rather than constructing fresh copy at request time.

The contract is intentionally specific about what is and is not included. It is a single-race lookup, not a list feed, and it is separate from the broader tips endpoint that can surface multiple selections. That distinction matters when you are building a race page, because you can request just the race in view and show its tip state without loading a full card of tips or assuming every race has a recommendation.

Many customers also use it as a status gate. Before rendering a tip block, the application reads the response and checks whether the race has an active selection for the saved analysis date. If not, the interface can hide the panel, show a neutral no-tip state or route the user to another part of the card. That keeps the presentation aligned with the saved data rather than implying a recommendation where none exists.

The endpoint is not designed for bulk browsing, so it works best when paired with the racecard feed or a race details lookup. Those services help you establish the page context; this one resolves the tip itself. That separation keeps the integration clean and helps editorial, trading and product teams maintain a clear distinction between race metadata and the saved recommendation attached to that race.

A clean integration often starts by passing the racecard ID and, where appropriate, the same display date used on the page. If you are building a timetable, race list or saved article view, the date parameter helps you keep the displayed tip in step with the card the user is actually viewing. That matters because the endpoint returns saved analysis rather than live re-analysis, so the date defines which saved record you are asking for.

When no qualifying selection is available, the response lets you detect that state instead of falling back to a fabricated tip. That makes the endpoint suitable for workflows that must distinguish between a valid saved selection, a race with no active recommendation and a race that is out of scope. In other words, the parameters help you request the correct record, and the response tells you whether there is anything safe to show.

If you already show bookmaker prices, the tip panel can be placed beside the latest odds snapshot without implying that the API is sourcing every market price in real time. The odds in this endpoint are the saved odds attached to the selection, while the dedicated odds feed is where you go for broader bookmaker price data. That separation is helpful when building pages that need both a recommendation and a market view, because each service retains its own role.

The best implementation pattern is to treat this endpoint as a final presentation lookup, not as a predictive engine call. Your app supplies the race ID, checks the returned status and then renders the tip only when the selection is present. That approach keeps the user journey fast to understand and protects you from showing a tip where the service has none to provide for that specific race/date combination.

It is also worth separating this service from the broader tips and explanations products. The single race endpoint is about one precise racecard record, whereas the multi-race tips feed is built for lists. The explanation is prewritten and exactly two sentences long, and it remains paired with the selection version that was saved beforehand. That pairing is part of the integrity of the response, so the client should preserve it rather than rewriting the wording in the browser.

For betting-style displays, the endpoint reflects saved odds and the bet type attached to the selection. It is not a promise of universal market availability, and it is not a guarantee of live, tick-level movement. That is why many teams pair it with the odds feed for a broader market view, while keeping this endpoint for the official saved tip message that belongs to the race itself.

For internal tools, the endpoint can power quality checks. Support staff, traders or editors can open a race ID, verify that the saved selection is the one intended for that date, and confirm that the paired explanation and bet type match the published presentation. Because IDs come from the feed, the workflow is reliable even when race names repeat across meetings or days.

If you are assembling a dashboard, this endpoint also works well as a detail drawer. A list of races can show a simple status indicator, and clicking one race can fetch the tip payload on demand. That keeps the page compact while still allowing a full explanation when a supported selection exists. It is a better fit than trying to preload a card of tips where only one race is relevant to the user’s current view.

The practical plan choice depends on traffic and how many race pages you expect to resolve. Developer includes 10,000 monthly requests at 2 requests per second for £29/month, Professional includes 100,000 monthly requests at 5 requests per second for £79/month, and Enterprise is £99.99/month with unlimited monthly requests at 10 requests per second. No VAT is added. Those limits matter most when you are deciding how often your UI will call the race tip lookup during a racecard session.

Because the endpoint is read-only and already saved, it fits cleanly into production front ends and editorial tools. It is also compatible with the wider RacingAPI.net suite, so you can combine it with racecards, results, odds, race details, horse profiles and other race-specific feeds to build a fuller page. The tip endpoint simply gives you the final saved recommendation for the one race the user is looking at.