Jockey Bookings and Connections API

The main purpose of /v1/jockeys/{id} is to give you a reliable daily view of a jockey’s bookings in the selected regional feed. The record is centred on the jockey ID from RacingAPI.net’s daily data, then expanded into the horse links that matter for publishing and user interfaces. That makes it useful when you want to show a rider profile page that does more than list a name and a silks image.

Because the feed is daily and regional, this endpoint fits products that care about today’s declarations, not a universal historical archive. You can present the jockey alongside the runners they are booked for, then add the horse-specific connections section to show contextual form information tied to that horse. It is a practical, racecard-first view rather than a broad statistical dossier.

The integration flow is straightforward. First, pull the relevant racecards or race data for the chosen feed date, then take the jockey ID exactly as supplied in that daily record. Pass that ID into /v1/jockeys/{id} with region=uk when you need the combined UK and Ireland feed. If you are building for tomorrow’s published declarations, use the tomorrow parameter instead of date; the two cannot be used together.

This design keeps matching deterministic. You are not expected to search by jockey name or guess at alternative spellings, and you should not rebuild the ID from display text. That matters if you are producing racecard pages, a “booked rides” drawer or an editorial panel where consistency across the feed is more important than broad-text search. The endpoint returns the daily connections exactly as recorded for that feed context.

The endpoint returns bookings for that jockey across declared horses in the selected daily feed, together with the horse-specific connections form section. That means your application can show the rider’s booked mounts and the related horse context in one place, without needing to make separate assumptions about which runners belong to that jockey. The result is suited to a jockey page, a card-based race interface or a “connections” tab within a race detail screen.

It is important to keep the scope clear. This is not a full career totals feed, not a lifetime win record, and not a replacement for long-range form analysis. The horse, jockey and trainer profile services in RacingAPI.net are daily-feed context products, so they should be used with the same mindset. If you need historical summaries or broader analysis, this endpoint should sit beside those pages rather than be treated as the sole source of truth.

Only region=uk is accepted. In RacingAPI.net terms, that single region covers the combined UK and Irish meetings in the relevant daily feed, so Ireland is not exposed as a separate region code here. That keeps the request model simple and makes the endpoint easier to use in products that already present one combined racing experience to their users.

You can also choose which daily feed you are querying. Use date when you want a specific YYYY-MM-DD feed snapshot, or use tomorrow when you want the documented tomorrow feed. These parameters are mutually exclusive. Because continuous archive completeness is not guaranteed, applications should be designed to work with the daily context available rather than relying on this endpoint as an exhaustive long-term archive.

A common implementation is a bookings panel beside a racecard. Your front end can start with a racecard list, group runners by jockey, and then call this endpoint for each distinct jockey ID you want to open into detail. That lets you show booked rides in a way that is easier for users to scan than a raw list of entries, especially when a rider has multiple mounts across the day.

You can also use the connection context to enrich a publisher-style profile page. For example, a race page might highlight the jockey’s booked rides, while a horse page can use the same endpoint to explain the horse-specific connection information for that rider. Because the ID comes from the feed, the page stays aligned with the daily declarations instead of drifting if display names vary between data sources.

For publishers, the value is in reducing manual linking. Instead of building a custom mapping between jockey names and racecard runners, you can keep your workflow anchored to the feed identifiers already present in RacingAPI.net. That is especially helpful if your site shows a jockey index, a race preview page and a horse page that all need to point to the same underlying daily record.

For internal products, the endpoint is useful as a display and workflow layer. Editors can confirm which horses are linked to a jockey in the selected feed, while product teams can place the data into panels, accordions or sidebars without inventing extra logic around selection. It is also a sensible companion to racecards and race details, because those services can provide the runner list while this endpoint provides the rider-specific connections view.

This endpoint is part of the core REST feeds available on all active plans. That means you can use it on Developer, Professional or Enterprise subscriptions without needing a separate add-on for basic API access. Account subscriptions, cards and invoices stay on-site, keys remain on the customer’s server, and access becomes available automatically after checkout confirmation. A one-time seven-day trial is available to eligible new customers after on-site checkout with a card; signing up alone does not start it, and it renews automatically unless cancelled.

If you are building a commercial product, remember that own-product display is allowed, but resale, onward API access and account sharing are not. Monthly quotas reset on the first UTC calendar day of each month, and the request rate depends on plan level. For this endpoint specifically, the service behaves like the rest of the core REST feeds: stable enough for production use, but still tied to the feed’s daily scope and accepted parameter rules.