Include time_text field in /meetings/{id}/ and /races/?date= endpoints
Hi team,
First of all, thank you for providing such a comprehensive horse racing API.
We understand that the individual race detail endpoint (/races/{id}/) exists specifically for in-depth race information like runners, odds, and full statistics. However, having time_text exclusively at that deep detail level presents a practical challenge when rendering meeting cards and schedule headers.
When displaying an entire meeting header or race pills across multiple tracks, having to fetch every single race detail endpoint just to retrieve one display value (the official post time) is an unnecessarily heavy operation for rendering a simple header.
Because start_time in the meeting list can sometimes differ from the official local post time, not having time_text at the meeting level prevents displaying accurate, real-world race times upfront on the meeting overview.
Our suggestion:
Could time_text (e.g., "16:20", "17:50") be included alongside start_time directly within the race summaries returned by /meetings/{id}/ and /races/?date=?
Key benefits:
1. Accurate Overview Headers: Consumers can render track headers and race ribbons with official, real-world post times immediately, without visual delays or initial timing discrepancies.
2. Better Resource Use: Deep detail endpoints can be reserved for what they are actually meant for (loading horses, jockeys, form, and odds when a user actively clicks into a race), rather than being called in bulk across every race simply to read a time string.
3. Instant Reflection of Delays: If a track reschedules post times, the meeting header will reflect the adjustment right away.
Thank you very much for considering this enhancement!
Resolution: time_text added to the race summaries in /meetings/{id}/ and /races/?date=.
Comments
3
Bzzoiro · Admin
Sep 11, 2026 15:44
Hi team,
You are right: time_text is only returned by the race detail endpoint, /races/{id}/. The race summaries in /meetings/{id}/ and /races/?date= carry start_time but not time_text, so showing the official post time on a meeting header takes a detail call per race.
Your reasoning holds, and the ticket stays open as the request. I cannot give a date for it yet.
Bzzoiro
Sep 17, 2026 06:13
Hi,
No movement to report, and I want to be straight about why rather than let it sit silently.
Your reasoning holds - rendering a meeting header should not cost a detail call per race, and start_time differing from the official post time is exactly the kind of thing that makes a header wrong. I am not disputing any of it.
But changing what an existing response returns is a decision about the API's shape, not a bug fix, and I am not making it on a ticket. It stays open as the request. I cannot give you a date.
Until then the detail endpoint is the only place time_text lives. If you are rendering a whole meeting, fetching its races once and caching the post times is cheaper than it looks: they do not move.
Bzzoiro
Sep 26, 2026 11:00
Done, and thank you for the patience — I told you twice that it stayed open without a date, and you were right both times.
time_text is now returned in the race summaries inside GET /meetings/{id}/ and GET /races/?date=, alongside start_time. Rendering a meeting header no longer costs a detail call per race.
Everything else about those responses is unchanged; the field was added, nothing was moved or renamed.
- Bzzoiro
Log in to comment.
