Horse Search API

This endpoint is a GET request at /v1/horses/search, and the core input is the q parameter. The search is case-insensitive and matches a substring of the horse name, so buyers can support partial-name lookups without forcing exact spelling. In practice, this is ideal for a search box with server-side debounce, where you only query after a short pause and then replace the dropdown or results panel with the latest matches.

The response is built around declared runners in the selected daily feed, not every horse ever recorded. That matters when you are designing the interface: the user is searching within a current region and date context, so the result set should feel like a live operational tool, not a historical archive. If nothing matches, the API returns an empty list rather than a special placeholder result, which keeps your frontend logic straightforward.

The scope is the combined UK and Ireland feed, accessed through region=uk. There is no separate Ireland region code for this endpoint, and other regional feeds are not part of customer access here. You can also choose a specific date with date=YYYY-MM-DD, or request the documented tomorrow feed with tomorrow=true, but those two controls cannot be used together. That makes the endpoint suitable for same-day planning, tomorrow previews, and date-specific runner discovery.

It is important to treat the returned horses as daily-feed context rather than a complete career-history dataset. A horse may appear because it is declared in the chosen feed, and that is the right behaviour for race-day products, not for exhaustive historical research. If your application needs profile pages or longer-running statistics, you would pair this search with the horse profile and form endpoints rather than stretching this one beyond its role.

The most useful implementation is usually a typeahead or lookup panel. A user enters a few characters, the frontend waits briefly, then requests matches and displays them as clickable rows. Because the API searches by substring, you can support people who only remember part of a name, and you can keep the UI compact by showing only the fields you actually need to let them choose the right runner. Once selected, that horse ID can feed the next step in your app.

That next step might be a racecard link, a profile drawer, a saved watchlist, or a back-office check for declarations. The key design point is that IDs come from the feed, not from name matching in your own code. Display names can change in presentation or appear similar across runners, so your app should always store the returned identifiers and use them for downstream requests. That protects you from ambiguous names and keeps navigation consistent.

A sensible integration usually starts with an input field, a loading state, and a small result list. When the user types, your application calls /v1/horses/search with q plus the relevant feed controls. If you are building around today’s cards, you use the default daily feed context; if you are building a future-facing workflow, you can switch to tomorrow=true, provided you do not combine it with date. The search is paginated, so your interface can request the next page only when a user scrolls or explicitly asks for more.

For API consumers, the main implementation decision is how much of the result list to expose at once. A limit value lets you control page size, while page gives you one-based pagination. Beyond the last page, the data array is empty and meta.total still reflects the total before pagination, which is useful if your UI wants to show the number of matches while allowing the user to continue paging. This is especially helpful in admin tools and analyst dashboards where people expect a full list view.

The returned rows represent unique declared runners in the selected feed. That means each match is tied to a live daily context, not a synthetic catalogue entry. If the same horse is relevant in a different feed date, it should be requested in that context rather than assumed from the earlier response. Your application should therefore treat the endpoint as a live selector that helps users locate the right runner at the right time.

This also affects how you present related information. If you want to show a horse profile card, keep in mind that the search endpoint itself is not the profile endpoint; it is the way into the correct horse identity. From there, a dedicated profile call can provide richer detail, while form statistics can add daily-feed performance context. Keeping these products separate gives you a cleaner architecture and a more trustworthy user journey.

A bookmaker-facing or analyst-facing product can use horse search to help users jump directly from a name fragment to the right runner. For example, a racecard page can offer a search field above a list of declared horses so that visitors can jump quickly to a runner’s row or profile. The same flow works in internal dashboards where traders, editors, or support staff need to locate a runner without scrolling through the whole card.

You can also use it to support saved lists, watchlists, or content management tools. If your users are editing preview content or cross-checking declarations, the endpoint gives them a controlled way to confirm which runner they mean before taking a further action. Because the endpoint is feed-scoped, it also helps prevent accidental lookups against irrelevant historical data when the task is clearly race-day oriented.

Horse Search API is part of RacingAPI.net’s core REST feeds on all active plans, so you can build the search feature without moving to a separate product tier. Keys stay on the customer’s server, which suits backend lookup flows and server-side rendering. The endpoint is accessed using your normal account access on the site, and subscriptions, cards, and invoices remain managed there as well. For a buyer, that means a clean setup: sign in, confirm access, and start wiring the search into your own application.

The commercial model is simple enough for product planning. Developer includes 10,000 monthly requests at 2 requests per second, Professional includes 100,000 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. New eligible customers can take one seven-day trial after on-site checkout with a card, and the trial only begins after that checkout confirmation. Renewal is automatic unless cancelled.