AI Horse Racing Tips API

This service exists to supply saved tips for publication, not to act as a freeform betting adviser. Because the response is stored retrieval only, it fits neatly into websites, apps and dashboards that need a stable tips section with consistent editorial rules. You can surface the latest active selections on a homepage module, power a premium tipster area, or feed an internal review screen that compares active and settled records by date.

The data scope is deliberately narrow and practical. You are getting selections for the combined UK and Ireland racing region, with the option to ask for a specific saved analysis date. That makes it useful for day-by-day publishing and back-office checking without implying universal coverage beyond the daily-feed context. It also avoids confusion between active selections, pending records and entries that should be treated as withdrawn, stale or otherwise not displayable.

The core call is a GET request to /v1/tips. You can leave the date out to retrieve the default saved set for today, or provide a date in YYYY-MM-DD format to pull the stored records for that analysis day. That distinction matters: the endpoint reads what already exists, so it is safe to use in production publishing flows without worrying about it quietly creating a new tip on demand.

Filtering happens before pagination, which is important for display logic. If you want a customer-facing page, request status=active so you only show tips intended for publication. If you are building an archive, report view or editorial queue, you can use the other statuses to inspect pending, no_selection, withdrawn, stale or settled records. Then apply page and limit so your interface can render manageable batches, with page counted from one and limit accepted from 1 to 100.

The saved tips are meant to support a publisher-style presentation, so the records can be used to show the basics punters look for first: the selection itself, the bet type, the odds used in the saved analysis and the relevant jockey and trainer context where supplied. The model estimates included with the record are best treated as model output, not calibrated guarantees. That gives you enough structure for a clear card or table without implying certainty or profit.

Where the feed includes saved explanations, those are fixed two-sentence notes prepared in advance and paired with the selection version they belong to. That pairing matters if you are caching or rendering historical pages, because the explanation should stay attached to the exact saved tip record rather than being re-generated later. If a record has no supported selection, do not invent a fallback tip or substitute a guess from another day.

Status handling is one of the main reasons this endpoint is useful in production. Active records are the natural fit for a live tips page. Pending records should be treated as not yet having a selection, so they are better suited to editorial workflows than public display. Withdrawn and stale records should not be shown as current tips, even if they remain useful for audit trails or internal history views.

Settled records are valuable when you want the same endpoint to support both a current view and a historical view. For example, your UI can default to active for public visitors and provide a separate archive tab for analysts or logged-in subscribers. Because the filter is applied before pagination, each view stays logically consistent: you are paging through one status group rather than mixing active and non-active records on the same screen.

A simple card layout works well if you want the tips feed to feel editorial. Each card can show the selection name, the odds from the saved record, the bet type, and a short explanation if one is present. A table is better if you want to compare multiple selections across a date, especially when you are showing active picks alongside settled or withdrawn items in a back-office interface. Either way, the key is to keep the display tied to the feed IDs rather than matching records by name.

If you are building a subscriber product, you can also use the endpoint as a source for sections such as "today's tips", "latest active selections" or "historical tips by date". Since the feed is read-only and stored, it suits cacheable pages and scheduled refreshes without the complexity of a generation workflow. Just remember that date-based retrieval returns saved records for that analysis day; it is not a live model request for new commentary.

Most teams will start by wiring the endpoint into a scheduled server-side fetch, then storing the response for rendering and review. A common flow is: request active tips for today, map the records onto your own presentation layer, and refresh on a schedule that suits your publication cycle. If you need an archive, add a date selector and pass the chosen saved analysis date back to the API so your UI stays in step with the feed.

From an access perspective, the endpoint sits within the Enterprise allowance and shares that 10 requests per second limit. Keys stay on your server, so the safest pattern is to keep the call server-side and expose only the formatted output to browsers or apps. That makes it easier to protect your credentials, enforce your own caching, and keep the account subscription, card and invoice administration on the site rather than inside your product.

The AI Horse Racing Tips API is part of the Enterprise plan at RacingAPI.net, which includes unlimited monthly requests and a 10 requests-per-second allowance for active plans at that tier. Access is automatic after confirmation, and eligible new customers can receive one seven-day trial after on-site checkout with a card. Sign-up alone does not start a trial, renewal is automatic unless cancelled, and monthly quotas reset on the first UTC calendar day of each month.

This endpoint is not a promise of profit, a universal racing history database or a live recalculation service. It returns stored positive-EV selections, with saved prices and model estimates, not calibrated guarantees. It also does not replace your own publishing judgement: if a record is stale, withdrawn or pending, you should follow the status rather than forcing it into a live tips section. That keeps the product accurate and the user experience clean.