Provider review · Horse-racing teams evaluating a compact REST contract
HorseAPI review
HorseAPI is a horse-racing API whose official Swagger interface describes live odds and results. The published contract exposes track discovery, race details and a bet-grading operation, with typed models for runners, results and payouts. That is a concrete starting point for a focused racecard or results integration, but it is not a coverage audit or proof of current service availability. This review separates documented schema from questions the public pages leave unanswered, including track scope, odds cadence, credentials, commercial rights and current access.
By Sarah MitchellUpdated
Our verdict
Editorial integration fit: 6.6/10. HorseAPI’s public Swagger contract is compact and directly relevant to horse-racing applications: track lookup, race detail and bet grading are supported by explicit response models. The documented runner and payout fields offer a useful implementation map. The lower score reflects diligence risk, not a conclusion that the API is unavailable: the accessible material does not establish present account access, current coverage, price, latency or redistribution rights. Treat it as a candidate for a credentialed proof of concept, not as a production-ready selection on documentation alone.
Key facts
- Advertised product
- The official Swagger description says HorseAPI provides live odds and results for horse racing. [1]
- API contract
- The official API specification is Swagger 2.0 and declares the host api.horseapi.com. [2]
- Documented routes
- The contract lists GET /tracks, GET /races/{track}/{race} and POST /grade. [2]
- Request pacing
- The description asks for at least 500 milliseconds between API calls. [1]
- Authentication
- Every listed route requires an Authorization header. [2]
Pros and cons
Pros
- The public contract names a small set of directly relevant operations: enumerate tracks, fetch a race, and grade a bet. That is easier to scope for an initial engineering evaluation than a sprawling undocumented endpoint list. The route set still needs a working account and concrete examples before a team can call it integration-ready.
- Race, runner, result and finishing-runner schemas provide a useful field checklist. Documented properties include race status, estimated start, surface, runner identity, scratches, jockey and trainer, odds, finishing position and payouts. These are meaningful building blocks for a race detail screen, though the schema does not guarantee every field is populated for every market or event.
- The provider’s documentation surfaces authentication and a minimum request interval instead of leaving both entirely implicit. An Authorization header and 500 ms pacing instruction let a developer identify two constraints early, plan a conservative client and request clarification before load testing. The accessible source does not specify a quota or demonstrate the practical behavior of those constraints.
Cons
- The public material does not publish a track-by-track or jurisdiction-by-jurisdiction coverage matrix. The broad phrase “live odds and results” is a product description, not evidence that a buyer’s target races, markets, histories or data fields are covered. That uncertainty is material for any application with a named launch calendar.
- Access and commercial terms remain unclear in the pages reviewed: there is no visible public price table, credential onboarding guide, service-level statement or clear grant of display and redistribution rights. A schema can help with coding but cannot answer whether the intended product may legally store, show or resell the feed.
- Current operating status and real-world feed characteristics cannot be inferred from the specification alone. The documentation declares an API and a 500 ms minimum interval, but it does not establish response freshness, uptime, settlement behavior or live account availability. Those points require direct verification with the provider and representative authenticated responses.
Provider website screenshots
A compact, horse-racing-specific API contract
HorseAPI describes itself in its official Swagger interface as a service for live odds and horse-racing results. Its API hostname is api.horseapi.com, and the interface links directly to a Swagger 2.0 specification. That makes the product identity and technical contract unusually visible compared with a marketing-only landing page. It does not, however, demonstrate how many tracks are carried, which jurisdictions are included, how frequently odds are refreshed, or whether all declared routes are currently operating. Treat those as diligence questions rather than fill gaps with assumptions.
The documented surface is narrow and recognizable: track discovery, a race lookup by track and race number, and a bet-grading operation. Its models expose track IDs and race counts, runner names and numbers, morning-line and odds strings, scratches, jockeys and trainers, race status, finish positions and payouts. These are useful ingredients for a racecard or result page. The short schema is not evidence that the feed covers every market or contains a complete wagering product.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
Three routes, each with a distinct job
The OpenAPI document lists GET /tracks, which returns an array of RaceTrack objects with an ID, name and race count. GET /races/{track}/{race} accepts a track identifier and integer race number and describes a Race response. POST /grade accepts a GradeRequest containing amount, bet type, race number, selection and track code, then describes a GradeResult with amount returned and a result string. A team can infer likely application flows from these schemas, but should not treat field names alone as a full operational guide to parameter values or settlement rules.
All three operations document a required Authorization header. The schema lists standard 200 responses and, depending on the operation, 201, 401, 403 and 404 responses. This communicates that authenticated access and error handling belong in the integration plan, but the accessible pages do not explain credential issuance, token format, account onboarding, or whether a particular response code is transient. Ask for sample requests and responses using a test credential before you design retries, caching or customer-facing error states.
Sources: [2] HorseAPI OpenAPI specification
Useful race and runner fields, with important boundaries
The Race model includes estimated start time, breed, distance, class, purse, surface, bet types, race number, status, runners, results and finishing runners. The Runner model includes name, number, age, gender, jockey, trainer, weight, saddle colour, scratch flag, odds and morning line. Result and finishing-runner structures expose result type, payout, winning ticket, finish position and win/place/show payoffs. This is a meaningful schema for joining a track list to a race view and presenting declared outcome fields after an event.
The breed enumeration is explicitly limited in the schema to THOROUGHBRED, THOROUGHBRED_LARC, HARNESS, QUARTERHORSE and ARABIAN; the race status enumeration names OPEN, RACE_OFF, FINAL and CANCELED. Those are documented enum values, not proof that every breed or status appears in live data. Nor does the schema say whether odds mean a particular pool or jurisdiction, when the morning line is populated, or how amended results are represented. Validate the event semantics, nullability and update behavior with representative examples.
Sources: [2] HorseAPI OpenAPI specification, [1] HorseAPI Swagger UI
A documented request interval affects architecture
The Swagger description says API calls require at least 500 milliseconds between requests. That is an explicit operational constraint and deserves attention before building a poller, race dashboard or batch backfill. The accessible specification does not define whether the interval is per token, account, endpoint or host, and it does not supply a separate requests-per-minute quota. Implement conservatively, centralize request scheduling, and get the exact interpretation in writing; do not infer a higher allowance from the absence of a published quota table.
Because the reference has only three routes, an integration proof of concept can be scoped tightly: list tracks, select a race, fetch its runners and results, then grade a controlled example with a test account if that operation is within the intended use. Build idempotent fetches and log the request IDs and timestamps your own system controls. Confirm data timezone conventions and race identifiers before normalizing them. These are recommended engineering checks, not tests we claim to have run against a working production credential.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
What the public contract leaves for procurement
The documents do not publish a track catalogue, competition or jurisdiction list, historical range, package table, prices, service-level commitment or data redistribution rights. They also do not define a streaming transport: the three visible operations are HTTP-style GET and POST routes in a Swagger contract. For a buyer who needs in-running odds, the product’s introductory phrase is not enough to establish refresh cadence or latency. Request a current coverage matrix showing track, meeting, race, market and time period, with concrete examples from the target jurisdiction.
Commercial evaluation should start with intended use rather than a generic quote. A publisher may need racecards and final results; a betting product may require market-specific price definitions, strict update timing and permission to display or derive data; an analytics team may need historical records. Ask separately about display, storage, caching, derivative products, geographic restrictions and permitted end users. Public source material does not answer those contract questions, so the review deliberately treats them as unresolved instead of inventing a plan or claiming that access is available today.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
A focused shortlist candidate, contingent on verification
HorseAPI is worth a technical conversation when the target product is specifically about horse racing and a small, typed route set is attractive. The track and race objects expose enough familiar fields to prototype a schedule-to-result experience, and the explicit grading route is a useful differentiator for teams that need to evaluate a supplied bet against a result. The spec’s named runner, payout and status properties also make it possible to identify required fields before requesting a trial payload.
The fit is weaker when a team needs a broad public catalogue, detailed commercial terms, documented historical depth, independently verifiable freshness or a tested self-service developer journey. The 6.6/10 editorial score is a cautious assessment of the visible schema’s relevance and clarity, discounted for absent public coverage and commercial details. It is not a rating of feed accuracy, live availability, latency, uptime, customer experience or price. Before ranking HorseAPI ahead of a competitor, verify credentials, a real target-track response and the licence that governs the planned product.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
Frequently asked questions
What does HorseAPI publicly document?
Its official Swagger pages describe track lookup, race lookup and a bet-grading operation, along with models for runners, odds, race status, results and payouts. The specification is useful for scoping a prototype but does not by itself confirm current access or coverage.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
Does the documentation identify which tracks are covered?
The published schema includes a /tracks route that returns track IDs, names and race counts, but the page does not list a current coverage catalogue. Ask for a dated track and jurisdiction matrix and test the specific meetings your product needs.
Sources: [2] HorseAPI OpenAPI specification
What authentication and request pacing are documented?
Each listed operation requires an Authorization header. The Swagger description also says API calls require at least 500 milliseconds between requests. The public pages do not explain credential issuance or the exact scope of the pacing rule, so confirm both directly.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
Can HorseAPI be used to display or redistribute odds?
The public documentation describes odds-related fields, but it does not establish display, storage, redistribution or commercial rights. Obtain written licence terms for the planned territories, audience and product behavior before relying on the feed.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
Is the API currently available and production-ready?
The public specification describes the API contract, but it does not prove present service availability, uptime or response freshness. Current access remains unverified here. Confirm credentials, test target-track responses and discuss operational commitments with HorseAPI before production use.
Sources: [1] HorseAPI Swagger UI, [2] HorseAPI OpenAPI specification
How our editorial ratings work
HorseAPI scores 6.6 out of 10. This is our editorial fit score, not a customer score.
Our scores are subjective website-integration fit assessments based on providers’ publicly described products, not customer-review averages or independent speed, uptime or accuracy tests. We consider publishing usefulness, integration options, documented data scope, access information and clarity of product documentation. A higher score is not a guarantee of suitability. BettorServe is the featured first placement; the remaining list is a curated shortlist, not an exhaustive market ranking.
This is a commercially oriented comparison site. We may earn a commission through eligible partner links, at no extra cost to you. BettorServe is our featured first listing. Commercial relationships and featured placements should be considered alongside the product details, and you should confirm current terms directly with a provider before purchasing.
Sources
Content last reviewed