Racecourse going and track conditions API

In RacingAPI.net, going is part of the racecourse or race context returned by the feed when available. Treat it as a published descriptor of the track state for that meeting, not as a derived weather summary. The value may appear in racecards, race details, or course records depending on the endpoint and the feed snapshot you request.

The practical advantage of this approach is consistency. If you display a racecard for a meeting, the going should match the feed payload you received for that racecourse and date. Do not normalise it into a home-grown scale unless your own product explicitly needs one, and even then preserve the original text beside any internal mapping.

The most direct places to look are the racecards and racecourse endpoints. The racecards feed includes meeting-level race information and can include going in the response fields. Racecourse details can also provide the course and its races from the selected feed, which is useful when you want to group multiple races by venue rather than by individual race.

For a specific race, /v1/races/{id} gives you the race record from a region-and-date feed. That is the best place to anchor a page that needs a single track condition for one event. If your interface starts from a course page, /v1/racecourses/{id} can supply the course context and its races from that same feed perspective.

Different meetings may run on different surfaces, and your UI should preserve the distinction instead of smoothing it away. If a feed item includes surface-related context, present it as part of the race description or course summary. That is especially important when comparing meetings on the same day, because two venues can sit under similar weather while still carrying different track states.

RacingAPI.net does not ask you to infer the surface condition from rainfall or temperature, and that restraint is deliberate. A rainy forecast does not automatically mean soft going, and dry weather does not guarantee fast conditions. If you want a user-facing summary, build it from the returned course and race context rather than from assumptions.

Going can change during the day, so the timestamp attached to the feed matters. When your application refreshes a racecard or course page, store the time the API response was generated or received and show it alongside the going. That way your users can see whether a track condition came from an early preview or a later update closer to the off.

For front-end performance, cached responses can help reduce repeated requests, but do not let shared caches mix personalised data or stale race state between users. Cache deliberately, revalidate when needed, and treat the feed timestamp as part of the data contract. If you are displaying a mutable condition like going, a clear last-updated indicator is more useful than pretending the value is static.

RacingAPI.net provides a separate course-weather endpoint at /v1/racecourses/{id}/weather. That feed returns UK and Irish course-location forecasts, with temperature, rainfall, wind and humidity, and it is available on every plan. It is valuable for operational context and for users who want to know what conditions may be developing around the venue.

However, weather is not official going. If you surface both on the same page, label them clearly and keep them in different UI fields. The weather feed should never overwrite the going returned by the race or course feed, and it should never be used as a shortcut for a track-condition prediction.

A clean implementation usually has three layers: the raw feed response, a normalised race view, and a presentation layer. The raw response should retain the exact going text, the race or course identifier, and the timestamp. The normalised layer can attach a human-readable label such as 'current going' or 'course weather', but it should not rewrite the underlying condition.

For users, the most helpful display is simple: the race name, the course, the official going if present, and a separate weather snapshot if you are showing it. That gives a complete picture without blending two different data sources. If you later add analytics, you can compare feed snapshots over time, but you should still keep each update tied to its own timestamp.