Racecourse Directory Feed API

This endpoint returns the unique courses that appear in the selected daily feed, with one row per course rather than one row per race. That makes it useful when you want a clean list of venues before drilling into individual cards or race details. Because the data is feed-based, the set of courses reflects the chosen day and region, not a static archive. Historical depth and completeness are not guaranteed, so it should be used as a current-meetings view rather than a career record of venues.

The response also includes source going when available, which helps you present an operational view of the day without trying to rebuild ground conditions yourself. You can use this to label meetings, group racing by course, or pre-filter a selector by surface conditions when the feed supplies them. Where the feed does not provide going, your interface should simply rely on the rest of the available course context rather than inventing a value.

A practical use case is a day-view selector that shows all courses with racing in the combined UK and Ireland feed. You can render each course as a card or list item, then allow the customer to choose the venue they want to inspect. Because the endpoint supports pagination, larger meeting days can be handled without forcing a single oversized response into the browser. That keeps the UI responsive while still giving you a complete course list page by page.

The selector works best when you pair the course list with other RacingAPI.net endpoints. For example, once a customer picks a course, you can move them into racecards for that day, a race details page for a chosen race, or the course detail and weather endpoints for a venue overview. The important part is to use the feed’s own IDs throughout. That keeps navigation stable and avoids brittle name matching when a course has similar wording to another venue.

The region parameter only accepts uk, and that one value represents the combined UK and Ireland feed. Ireland is not exposed as a separate customer region code on this endpoint. If you are building a market-facing product, that distinction matters: your users will see a single operational feed for the relevant day, rather than a country split they have to reconcile themselves. Other regional feeds are excluded from customer access here.

This makes the endpoint especially useful for products that need a simple “today’s racing” landing page. Instead of stitching together multiple lists or maintaining your own directory of courses, you can use the combined feed and let the course IDs determine what appears. The result is a cleaner integration path for apps, dashboards and back-office tools that need to understand where racing is taking place today, without pretending to be an all-time venue index.

A straightforward implementation starts with a GET request to /v1/racecourses for the day you want to show. You can request today by default, or use the documented tomorrow feed when you want to let customers preview the next day’s meetings. If you need a historical or retrospective view, pass a date, but keep in mind that completeness and depth are feed-led rather than guaranteed as a full archive. The endpoint also supports page and limit so you can control how the list is delivered.

Once you have the courses, store or pass along the course IDs and use them as the link points into the rest of your RacingAPI.net build. A venue page may show course details, weather, racecards and the races themselves, while the selector can return users to the course list at any time. Because this product is a list feed, not a single-record lookup, it is best used for browsing and discovery rather than looking up one known venue by ID.

This service is particularly useful when you want to combine the racecourse list with weather and going context. The feed can include source going when available, while the separate Racecourse Weather API gives you forecast data for the same course ID. That separation matters: going is the race feed’s own condition context, while weather is a forecast with its own attribution and expiry. Presenting both together gives your users a fuller picture without blurring one into the other.

A good interface will show the course name first, then display going, then place weather alongside it as a distinct layer of information. That helps customers understand whether the day’s meeting selector is based on racing data or weather data, and it keeps your product honest about where each value comes from. If either source is absent for a given course, the correct approach is to leave that element out rather than making assumptions.

Course IDs are the backbone of the integration. They are issued by the feed, and they should be treated as the authoritative way to connect a course list item to other RacingAPI.net services. That is more reliable than matching on names, especially in interfaces where users may browse quickly or where a venue name appears in more than one context. Building around IDs also makes it easier to preserve links between lists, details and weather records over time.

Pagination is also important because this endpoint returns a list, not a single item. The page parameter is one-based, and if you go beyond the final page the data comes back empty while meta.total still reflects the total before pagination. That behaviour is useful for client-side list controls, infinite scroll and admin tools, because it lets you keep the total count visible while still paging through the feed in a controlled way.

This endpoint is best thought of as the course index for the day’s racing workflow. It does not replace racecards, race details, results or horse-level endpoints; instead, it helps you organise them. If your product is built around a “today’s meetings” or “browse by course” journey, this feed gives you the first stable layer. From there, you can send the customer into the racecards page, open the race detail record for a selected event, or add course-specific weather context.

Because the feed is available on all active plans, it can sit at the centre of both small and larger integrations. A developer can use it for a simple meeting list, while a more advanced platform can use it as part of a route that joins together course detail, race data and weather. The key is to keep the scope narrow: it is a live course list for the selected day and region, not a promise of exhaustive historical venue coverage.