What data can you get from our horse racing API?

The core of the catalogue is the daily racing feed. Racecards return UK and Irish meetings with declared runners, and the race details endpoint expands a selected race into its own structure. That means you can build a race-day view from the feed rather than stitching together separate sources. The catalogue is intentionally feed-first: you receive the races that are present for the requested region and date, not a complete long-term archive of every historical meeting.

Results are exposed separately from racecards, with finishing positions and the result data available for a chosen race. That split is important if your application needs to show ante-post information first and later reconcile it with the finishing order. The result family is designed for what happened in the race, while racecards are designed for what is declared before the off.

Horse search and horse profiles are both scoped to the declared daily feed. Search helps you find runners in that feed, while the horse profile endpoint returns the runner record and the form summary that is available for that horse in the selected context. The key point is that this is not a complete career database. If you need every run a horse has ever had, you should not expect that from this catalogue.

The horse form statistics endpoint is especially useful when you need race-specific context: race record, conditions, headgear, class rating and connections where present. Availability varies by horse and by the daily feed in question. In practice, this makes it well suited to race cards, shortlist tooling and in-race analysis where the objective is to surface what is relevant today, not to reconstruct an exhaustive biography.

RacingAPI.net exposes jockey and trainer connection endpoints to show how the declared runners relate to their connections inside the selected feed. These are not career-statistics products. They are designed to answer questions such as which horse a jockey is booked to ride, which runners are declared for a trainer, and what horse-specific connection statistics are available in that daily context.

That makes them useful for racecards, comparison views and internal tooling where you want a pragmatic snapshot rather than a historic leaderboard. The catalogue explicitly does not present these endpoints as full career databases, so developers should avoid interpreting the figures as comprehensive all-time records. If you present them in a user interface, the safest pattern is to label them as feed-scoped connection data.

The course family includes racecourses that appear in the selected regional feed, plus a course detail view that expands a specific track into its races. As with the rest of the catalogue, this is feed-aware rather than a universal directory of every racecourse that might exist in theory. It is meant to support the meetings currently present in the region=uk feed, which includes both UK and Irish cards.

Weather is available as a separate racecourse endpoint and is not the same thing as official going. The weather feed provides course-location forecasts from MET Norway, including temperature, rainfall, wind speed, humidity and the forecast source. Because the forecast is sourced and attributed, your application should retain the returned attribution and treat the weather data as a distinct layer alongside official going, not a replacement for it.

The odds endpoint returns bookmaker prices observed in the live UK feed. The design choice here is to preserve the source price strings and the bookmaker identifiers rather than forcing them into a normalised odds model. That means you can surface what was observed, compare prices, or display each-way information where present, but you should not assume guaranteed bookmaker coverage, a standard price format or a fixed refresh interval.

For media, RacingAPI.net supplies racing silks as validated PNGs for declared horse and race IDs when image-feed access is enabled. These are not photographs and should be treated as colour assets for runners, ownership or race presentation. Missing images return 404, which is useful when you are building a graceful fallback in a user interface.

Enterprise adds live AI-assisted tips as an active product feature rather than an experimental preview. The tips family includes pre-generated selections with saved explanations, status, versioning and observed odds context. There is also a race selection endpoint and a separate explanation endpoint for retrieving the same saved two-sentence explanation without re-running AI. These are designed to be read as live insight feeds, not as guarantees of outcome.

For compatible AI clients, Enterprise also includes a read-only MCP server. This is not a separate racing dataset; it is a controlled access method for the same Enterprise capability set. Access is through explicit OAuth consent or an API-key header in supported developer clients. Enterprise MCP calls share the Enterprise rate limit and monthly quota rules, so they should be treated as part of the normal API usage model, not as an unlimited side channel.

Before you integrate any feed family, it helps to understand the access rules because they shape what data you can actually retrieve. Requests are made to https://racingapi.net using the X-API-Key header, and the key stays server side. Access requires a completed card-required seven-day trial checkout or an active subscription; signup alone is not enough. There is no permanent free tier, and monthly usage is counted across all keys against the same account.

The available catalogue is UK and Ireland only, via region=uk. That single region includes both countries, and requests for other regional feeds are rejected. You should also treat historical depth carefully: horse form, connection data and course coverage are feed-scoped, not universal historical warehouses. If your product needs a complete career chronology or a full market-wide dataset, this catalogue is not designed to promise that.