Racecourse Details API

The endpoint at /v1/racecourses/{id} returns course details for the chosen racecourse together with the races that belong to that course in the selected daily context. That makes it suitable for front ends that need more than a plain directory entry. You can show the venue and the day’s card on one screen, while still keeping the data model anchored to the feed record that supplied the ID in the first place.

The contract is deliberately specific: it gives you a course and its daily races, not a course geometry layer, not a picture archive, and not a historical directory of every meeting ever staged there. That scope is useful because it keeps the response tied to the current feed selection. If your product needs wider browsing, you can pair this endpoint with the racecourse directory feed, but this service is the one to use when the user has already chosen a track and you want to render the matching meeting data.

The path parameter id is an opaque resource ID copied from the matching field in the selected daily feed. It should be treated as a string, and your integration should store it exactly as supplied. This matters because course identity comes from the feed itself, not from a free-text search or an assumption that a venue name will always be enough to locate the right record.

In practice, the best workflow is to take the course ID from the daily feed your app already consumes, then hand that ID to this endpoint when the user opens the racecourse page. That keeps the page consistent with the daily meeting context and avoids inventing cross-feed matches. If you already list courses elsewhere in your application, this endpoint is the detail layer that confirms the course and attaches the day’s races to that same record.

This service accepts region=uk only. That single combined feed includes UK and Irish meetings, so Ireland is not a separate region code in customer access. If your product is region-aware, the simplest setup is to treat uk as the only supported selector for this endpoint and use the course ID from the corresponding daily feed record you have already loaded.

You can also target a particular feed day by passing date in YYYY-MM-DD format, or use tomorrow=true to select the documented tomorrow feed. Those selectors cannot be combined with each other, so your UI should present them as an either-or choice. This is useful when you want to let a user review the next day’s racecourse page in advance, while keeping the data tied to the feed snapshot you asked for.

A common use case is a venue landing page that starts with the course name and then shows the daily races underneath. The same response can drive the page header, the race list, and contextual links into each race detail page. If you are building a desktop dashboard, this endpoint can also sit behind a left-hand course navigation panel so users can move from one venue to another without leaving the daily feed context.

For mobile products, the endpoint works well as the payload behind a compact course summary card. You can show the course details first, then fold the meeting races into a list that expands on demand. Because the data arrives from a single course ID, the page can stay focused on one venue rather than forcing the user to scroll through a mixed-day racecard. That makes it a good fit for event-led browsing, meet-specific widgets, and racecourse tabs in a broader racing interface.

One of the most useful ways to present this endpoint is alongside a separate weather panel. The course details response gives you the racecourse context, while the Racecourse Weather API provides MET Norway forecasts with attribution and expiry. That separation matters because weather is not the same thing as official going, and users usually want to see both without assuming they mean the same thing.

If your interface displays course conditions, keep the source labels clear. Official going belongs with the racecourse context returned by the feed, while the weather forecast should be shown as a separate forecast module. This gives your product a better structure: users can review the course, read the daily meeting list, and then consult the forecast panel without mixing a forecast with the official track state. That is especially helpful when the venue page is used as a pre-race planning screen.

The endpoint is designed to reflect the daily-feed context. It is not a universal career-history database for horses, jockeys or trainers. If you need deeper biography or form data, those are separate services. Here, the role of the course endpoint is to tell you which races belong to that meeting and to keep the course identity anchored to the feed snapshot you selected.

That same principle applies to other supporting content. Silks are owner colours supplied as PNG images, not portraits, and they should be treated as a visual aid rather than a full profile asset. Odds, if you use them elsewhere in the product, are bookmaker prices supplied as prices, not a guarantee that every bookmaker will be available or that updates happen on a tick-by-tick basis. Keeping each dataset in its own lane makes the venue page easier to maintain and explain.

A clean implementation usually follows four steps. First, load the daily feed and capture the course ID attached to the venue your user has selected. Second, call /v1/racecourses/{id} with the chosen region=uk and, where needed, date or tomorrow. Third, render the course details and the race list in your page or component tree. Fourth, link each race through to the individual race details endpoint when the user wants a deeper view of runners, market data or race-level context.

If your platform uses server-rendered pages, the response can populate the initial HTML for the racecourse view before the user interacts with it. If you are building a client-side app, you can fetch it after the user selects a venue from the daily meeting list. Either way, the important design choice is to keep the course page keyed to the feed ID and to treat this endpoint as the source of the course-plus-meeting view, not as a search engine for venue names.

Core REST feeds are available on every active plan, so this endpoint is included in the normal product set rather than being reserved for a separate add-on. The plans are Developer at £29 per month with 10,000 monthly requests and 2 requests per second, Professional at £79 per month with 100,000 monthly requests and 5 requests per second, and Enterprise at £99.99 per month with unlimited monthly requests and 10 requests per second. No VAT is added.

New eligible customers can get one seven-day trial after on-site checkout with a card. Sign-up alone does not begin a trial, and subscriptions renew automatically unless cancelled. Access is automatic after confirmation, while account subscriptions, cards and invoices stay on-site. Monthly quotas reset on the first UTC calendar day of each month. API keys stay on the customer’s server, and the rules allow own-product display but not resale, onward API access or account sharing.