Horse Form Statistics API

The endpoint returns every supplied summary form row for a horse, grouped by section. In practical terms, that means a clean, machine-readable view of the horse’s race record context and the condition-based panels that are present in the selected feed. If the feed includes headgear, class rating or connections data for that declaration, those rows are included; if they are not supplied, they are simply absent rather than inferred.

That distinction is important when you are building a commercial interface. You are not getting a fabricated “best form” narrative or a hidden computed ranking from historic results; you are getting the feed’s own supplied summary layers. This makes the endpoint suitable for display, filtering and internal comparison, particularly when you need consistent panels across racecards, horse pages and form tabs.

The horse ID is opaque and should be copied from the corresponding field in the selected daily feed. Do not try to recreate it from the horse name, because IDs come from the feed and are the only reliable way to address the resource. If you are building a racecard or horse-search workflow, the usual pattern is to capture the ID from the list view and pass it straight into this endpoint.

The raceId parameter keeps the form view tied to the correct declaration. That matters because the same horse can be declared in different contexts within the same feed, and this endpoint respects that structure. If you include raceId and it does not match one of the horse’s declarations, the request returns 404. If you omit it, the first declaration in feed order is used and identified, which is useful for default display but should be explicit in your UI copy.

A straightforward implementation usually starts with a horse list or racecard endpoint, then links each runner to this form endpoint on demand. For example, you can add a “Form statistics” tab on a horse page, a hover panel in a racecard, or a side-by-side comparison for analysts. Because the endpoint is read-only and part of the same daily feed model, it fits naturally into a front end that already knows the horse ID and the active feed date.

You can also make the date choice visible to users. The contract supports either a specific YYYY-MM-DD date or the documented tomorrow feed, but not both at once. That lets your application keep a clear “today / selected date / tomorrow” selector while staying aligned with the feed’s own context. If your interface is used for editorial review or pre-race preparation, that date awareness can be shown as a badge or filter state rather than hidden in the query string.

The service is limited to UK and Ireland under region=uk. That combined region is deliberate: Ireland is not a separate code here, and other regional feeds are excluded from customer access for this endpoint. This keeps implementation simple for customers who need one cross-border racing view rather than multiple regional branches, while still preserving the feed structure exactly as delivered.

The data scope is also intentionally narrow. Horse, jockey and trainer profiles are daily-feed context, not universal career databases. Likewise, this endpoint does not convert summary rows into a complete line-by-line run history. If you need race-by-race results, race details or a broader profile view, those are separate products. This endpoint is specifically the supplied form-statistics layer that sits neatly between horse identity and race context.

Commercial users usually place this data where a quick decision or quick read matters. A sportsbook-style dashboard might show the grouped rows beneath the runner name, while a media site might use them as a compact research block under the racecard. Because the endpoint returns the supplied sections as-is, you can preserve the same structure across web, mobile and back-office tools without inventing a new interpretation layer.

You can also use the endpoint to support internal workflows. Traders, editors and racing analysts may want the declaration-specific view in order to compare horses across the same race card or check whether a particular condition-related panel is present in the current feed. Since the endpoint returns missing values as empty strings, your application can keep its layout stable while still allowing for partial data when the feed does not supply every row.

A declared horse with no supplied form still returns successfully, but with form: []. That is useful if you want to distinguish between “no form supplied in feed” and a request failure. It also means your code should not assume that every declared runner will have visible summary statistics. Handle the empty array as a valid display state, not an exception.

The endpoint also supports the usual API response controls you would expect from a production feed: 401, 403, 404, 405, 422, 429, 500 and 503 are all part of the contract. In a customer interface, the practical approach is to retry cautiously on transient server responses, surface rate-limit messaging when needed, and present a clear “not available for this declaration” state for 404s that result from a non-matching raceId.

This endpoint is available on all active plans as part of RacingAPI.net’s core REST feeds. The current plan structure is Developer at £29 per month for 10,000 monthly requests at 2 requests per second, Professional at £79 per month for 100,000 requests at 5 requests per second, and Enterprise at £99.99 per month for unlimited monthly requests at 10 requests per second. No VAT is added. Monthly quotas reset on the first UTC calendar day of each month.

New eligible customers can receive one seven-day trial after on-site checkout with a card; sign-up alone does not begin a trial, and the subscription renews automatically unless cancelled. Access is activated after confirmation. Account subscriptions, cards and invoices stay on-site, and keys remain on the customer’s server. Customers may display their own product using the API, but resale, onward API access and account sharing are not permitted.