Horse Racing Silks API

The endpoint at /v1/silks/{id} is a GET request that returns racing-colour artwork as a PNG. You provide the horse ID in the path and the race ID in the query string, and both must refer to the same declared runner in the same selected daily feed. The service does not wrap the image in JSON, so your client should treat the successful response as binary image data rather than a metadata object.

That makes the endpoint especially useful when you need to place silks inside a racecard, runner row, form table or “watch this race” screen. It is also a good fit for server-side image proxying, because you can fetch the PNG from RacingAPI.net and deliver it through your own application layer while keeping your presentation logic consistent. The API is built for actual race display, not for producing abstract asset catalogues.

The endpoint also supports date and tomorrow selection, which helps when you are building tomorrow’s cards, pre-race dashboards or historical dated views from the feed. These options are mutually exclusive, so your request should choose either a specific date or the documented tomorrow feed, not both. Region is fixed to uk, which in this product means the combined UK and Irish meeting feed rather than a separate Ireland code.

A practical implementation usually keeps a small mapping layer in your app that stores runner IDs from the relevant racecard response and passes them directly to the silk call when the page needs to render. That pattern is reliable, easy to test and straightforward to secure. You can also build graceful fallbacks in your own interface, such as a neutral placeholder box when the API responds with 404, without inventing a replacement silk.

This service is limited to declared runner silks in the regional daily feed. It is not a portrait gallery, and it does not provide horse, jockey or trainer photographs. The asset is the owner racing colours represented as a PNG, which is the correct visual element for racecards and live race coverage. If you need descriptive information about the horse, jockey or trainer, those come from the relevant profile or racecard products rather than from this image endpoint.

Because the image is tied to a race context, your request must use a horse ID copied from a runner in the selected race and a race ID from the same region and day. That specificity matters for accuracy: the same horse ID is only valid where the feed says it is a runner in that race. The service is therefore a presentation layer for a specific day’s declarations, not a universal image lookup by horse name or an archive of every past appearance.

Coverage is partial, so not every declared runner will necessarily have a matching silk image available through the endpoint. In those cases the API returns 404 and leaves the choice of UI treatment to you. That makes the service suitable for applications that want clear control over whether to show the image, a placeholder or a text-only runner row, without any hidden substitution by the API itself.

For accessible racecards, the PNG can be used as a visual cue alongside text labels such as horse name, number, jockey and trainer. That works well when the silk is part of a structured runner card rather than a standalone decorative image. You remain responsible for your own accessible markup, but the endpoint gives you a stable visual asset that can sit cleanly inside a keyboard-friendly, screen-reader-aware layout.

If you are building a custom racecard view, you can fetch the silk server-side and serve it from your own domain with an alt-text strategy that reflects the runner’s name and race context. Since the API provides the image only, the surrounding accessibility choices belong in your application design. This is useful for publishers, data platforms and race apps that want consistent presentation across mobile and desktop without exposing raw feed calls in the browser.

The combination of race ID and horse ID also helps you keep the right silk aligned with the right runner in fast-moving views such as live cards or filtered race lists. If a user changes race, date or tomorrow view, you can refresh the image against the new context rather than reusing an old asset. That reduces the risk of showing the wrong colours when the same horse appears in a different race or when your UI reorders runners dynamically.

If you are building a paid race product, you can combine silks with racecards, race details and results without having to send users away from your own interface. The silks endpoint is therefore a visual companion to other data services, not a separate media marketplace. Because it is tied to runner IDs, it slots neatly into any workflow that already stores or passes those IDs through your own pages.

The key operational rule is simple: use the horse ID from the feed, pair it with the correct race ID, and call the endpoint only within the selected regional day context. That keeps the image request aligned with the declared runner record and reduces confusion when you render multiple races in one session. It also makes testing much easier, because you can compare your UI output against a single known race context.

The request shape is intentionally narrow. The path includes the horse ID, while the race ID sits in the query string, and only the uk region is accepted. That region represents the combined UK and Ireland feed for this product, so there is no separate Ireland code to manage. You may also use date or tomorrow to choose the feed context, but those parameters cannot be combined with each other.

Successful responses return a binary PNG. If the image is missing, the endpoint returns 404 rather than inventing a substitute or giving you an unrelated visual. That behaviour is valuable when you need deterministic rendering in your own code, because it lets you branch clearly between “image available” and “image not available”. The other documented response codes cover the usual request, permission, rate and service conditions in line with the API contract.

The practical takeaway is that this is a precise image lookup, not a search endpoint. You should not pass arbitrary horse names, and you should not expect the service to resolve loosely matched text. It is built for systems that already have the feed identifiers and want to turn them into a consistent visual asset in the correct race context.

The silks endpoint is strongest when used alongside racecards, race details and horse profile data. For example, a racecard page can load runner data from the racecards feed, open the race details view when needed, and request the silk PNG for each declared runner. That keeps presentation and content separate while still giving your users a polished racing interface. The same pattern works for desktop race hubs, mobile apps and internal editorial tools.

You can also use it in a server-rendered environment where the backend fetches the PNG and passes it through an image cache or proxy layer. That approach is useful if you want to avoid exposing the direct API call in client-side code. It also helps when you need controlled asset delivery for a public-facing race page, because the image can be returned in the same visual framework as the rest of your site.

If your product includes saved race views, alerts or “today’s racecards” modules, the silks feed can be the finishing touch that makes the display recognisable at a glance. It does not replace the core structured data, and it is not intended to stand alone. Instead, it gives you the exact colour asset linked to the runner and race you are already displaying, which is what makes it commercially useful in a production race interface.