Horse racing API licensing and API-key security

For most integrations, the clearest permitted use is own-site display: your application may consume RacingAPI.net data and present it on your own site or product interface. That can include racecards, results, odds, horse profiles, weather and, where enabled on the plan, Enterprise tips. The important boundary is that the data stays inside your own customer experience rather than becoming a feed you expose to unrelated third parties.

What is not permitted is feed resale or account sharing. You should not let another business, another developer or another end customer use your account as a back door into the same data. If you are building software for a client, structure it as your own implementation against your own account or the client’s own account, rather than a shared pool of credentials.

Because account sharing is not allowed, your internal process should make one account mean one responsible owner. If you work in a team, create a clear internal rule that only approved staff can access the dashboard and the key-management area. Do not paste the key into shared chat, ticketing notes or handover documents unless your organisation has a controlled secrets system that limits access.

If you deliver software on behalf of a client, keep the client relationship separate from your own operational access. The account holder should be able to understand who can see the key, who can rotate it, and who can request revocation. This is a governance issue as much as a technical one, because a forgotten shared password can become an unauthorised distribution route.

The safest implementation is to call RacingAPI.net from your backend and let your server attach the X-API-Key header. That keeps the credential away from browser source, public JavaScript bundles and client-side logs. It also makes it easier to centralise request handling, rate-limit awareness and error handling in one place.

Do not rely on obfuscation. A key hidden in frontend code, embedded in a mobile app, or stored in a downloadable config file is still a secret that can be extracted. If your architecture needs the browser to show data, let the browser talk only to your own backend, and let your backend talk to RacingAPI.net.

Store keys in a proper secrets system or encrypted environment variables, not in source control. The main risk is not only theft, but accidental disclosure through build logs, deployment previews, database backups and support exports. Any place that can be copied or searched by many people should be treated as hostile to secrets.

Logging needs the same discipline. Never log the full X-API-Key, and avoid recording request headers in verbose debug output. If you must trace authentication issues, redact the value and keep only enough context to identify the request. The same applies to screenshots and pasted error messages: remove the secret before sharing with colleagues or support.

You should be able to rotate a key as part of routine maintenance, not only after an incident. A sensible pattern is to introduce the new key, deploy it to your backend, confirm the service is using it, and then revoke the old one. That sequence reduces the risk of an interruption while still closing the old credential promptly.

Revocation matters when staff change roles, a repository is exposed, or a secret appears in the wrong place. If there is any doubt, revoke first and restore service with a fresh key. Because usage is aggregated across keys on the account, treat rotation as a security action rather than a billing workaround.

A good audit trail should show who asked for a key change, when it happened and why. That does not mean storing secrets in the audit log; it means recording the administrative event around the secret. Keep ticket references, deployment notes and access approvals separate from the actual credential value.

Where practical, minimise the number of people who can view or change the key. If your team expands, review whether everyone still needs direct access to the dashboard. The smaller the trusted group, the easier it is to maintain compliance with the no-sharing rule and to respond quickly if access is compromised.