Horse Profiles API

This endpoint returns the horse as it appears in the selected daily declarations. That means the profile is tied to the raceday context you have asked for, including the declared runner’s connections and the form information supplied with that feed. It is a practical panel for answering the user’s immediate question: who is this runner, how is it entered today, and what context is available for this declaration?

It is not a complete career record and should not be presented as one. The contract is explicit that the horse profile reflects the selected feed rather than a universal historical database, so the safest product approach is to frame it as a current-declaration view with related form context. Where strings are missing, they come back empty; where collections are missing, they come back as empty arrays, which makes the endpoint predictable to render in a UI without inventing placeholders.

A common integration is to start with the racecards feed, list the declared runners, then open this endpoint for the runner that a user selects. That gives you a clean drill-down from race-level context into horse-level detail without storing a separate profile model. Because IDs come from the feed, the recommended pattern is to persist the horse ID alongside each runner entry and pass that through unchanged.

This also works well for multiple front-end views. A compact racecard tile can show the horse name and a few headline values, while the detail drawer or full page uses the horse profile endpoint to display the fuller declaration context. If you need race-specific context as well, combine it with the Race Details API for the race itself, rather than overloading the horse endpoint with race metadata it does not own.

Integration starts with the path parameter: the horse ID is an opaque resource ID copied from the corresponding field in the selected daily feed. Treat it as a string and store it exactly as delivered. That avoids brittle lookup logic and keeps your system aligned with the declarations in the feed snapshot you are rendering. This is especially important when the same horse may be visible in different dated feeds or in tomorrow’s preview feed.

The query options are deliberately narrow. Only region=uk is accepted, and that single combined feed includes both UK and Irish meetings. You can also pass date in YYYY-MM-DD form to retrieve a specific day, or tomorrow=true to select the documented tomorrow feed, but those two cannot be combined. The date-based response should be treated as feed-context data for that day, not as a guarantee of continuous archive completeness.

The profile is useful because it brings together the pieces a punter or trader typically wants when opening a horse. You can surface the horse’s connections, the supplied form statistics and the bookmaker prices that are available in the feed. That lets you build a practical profile panel without forcing the user to jump between separate screens for basic runner context and market context.

The prices are bookmaker prices supplied in the feed, so they should be presented as available prices rather than as a promise of universal coverage or tick-level updating. That distinction matters in product design: use the endpoint to show what the feed currently supplies, and leave live market-refresh behaviour to your own refresh strategy if you need it. The horse endpoint is a declaration view, not a market microstructure feed.

For a richer runner page, the Horse Profiles API works best as one part of a connected set of endpoints. If you need deeper form presentation, the Horse Form Statistics API is the obvious companion. If you want to show rider or stable context on the same page, the Jockey Bookings and Connections API and the Trainer Runners and Connections API let you link the horse to the people involved without forcing this endpoint to carry everything.

You can also combine it with the Horse Racing Silks API for owner colours. Those silks are PNG owner colours, not portraits, so they suit visual identification on racecards and detail pages. If your product wants to show where the runner is competing, the Racecourse Directory Feed API and Racecourse Details API can add venue context, while the Racecourse Weather API gives a separate weather forecast with attribution and expiry. That forecast is distinct from official going.

A typical implementation begins with authentication on your server, then a fetch from the racecards or search endpoint, and then a horse profile lookup using the copied ID. From there you can render the runner card, open a detail panel or enrich a betting workflow. Because keys stay on the customer’s server, this is a server-side integration rather than a browser-exposed one, which keeps your application structure cleaner and easier to control.

The endpoint is suitable for products that need to assemble a raceday journey: browse the card, inspect a runner, cross-check the same horse across its declared context, and then move into odds or tips if your plan includes those products. Core REST feeds are available on all active plans, so the Horse Profiles API sits within the standard product set. If your business needs saved explanations, tips or MCP tooling, those are Enterprise-only additions rather than part of this endpoint itself.

The Horse Profiles API is available on all active plans as part of the core REST feeds. Developer includes 10,000 monthly requests at 2 requests per second, Professional includes 100,000 monthly requests at 5 requests per second, and Enterprise includes unlimited monthly requests at 10 requests per second. Monthly quotas reset on the first UTC calendar day of each month, and access is activated automatically after confirmation.

Subscriptions, cards and invoices stay on-site. New eligible customers can obtain one seven-day trial after on-site checkout with a card; sign-up alone does not begin a trial, and the trial renews automatically unless cancelled. Own-product display is allowed, but resale, onward API access and account sharing are not. If you only need horse profile data, you do not need Enterprise; if you also need saved explanations or MCP access, those products sit at Enterprise level.