API key security and data licensing for football products

Keys belong on servers you control, in environment variables or a secret manager. They never belong in browser code, mobile app bundles, public repositories, screenshots, support tickets or chat messages. A key in a mobile app can be extracted in minutes, and a key in a public repository is often found by automated scanners within hours.

If a front end needs data, it should call your server, which reads from its cache. The key stays in one place, behind your own authentication and rate limits.

FootballAPI.net stores only a hash of each key and shows the secret once, at creation or rotation. If you lose it, rotate rather than asking for it to be recovered.

Create separate keys for production, staging, development and each distinct service. Name them clearly in the dashboard. Separate keys let you rotate one without disrupting the others, and your usage page shows which key made which calls, which helps when investigating unexpected activity.

Give developers their own development keys rather than sharing production ones. When someone leaves the team, revoke their keys.

Rotate keys on a schedule, for example quarterly, and immediately after any suspected exposure. Rotation issues a new secret and stops the old one working at once, so plan the update: deploy the new secret to the service, then confirm requests succeed. Document the procedure so anyone on call can do it calmly.

Keep a short log of rotations with dates and reasons. It helps during audits and incident reviews.

Revoke or rotate the key immediately from the dashboard. Then check the usage page for unexpected requests, remove the key from wherever it leaked, including repository history if necessary, and review how it happened. Tell support if you see activity you cannot explain.

Speed matters more than perfection. Revoke first, investigate second.

Football data is licensed for display in your own product. That typically means showing it to your users on your site or app. It does not mean reselling the feed, publishing bulk downloads, sharing your key with partners or building a competing data service. If your use case goes beyond display in your own product, ask before building it.

Images such as crests and player photos follow the same terms and should be served through our media route rather than copied into public storage.

Club crests and competition names are trademarks of their owners. Use them to identify clubs and competitions in context, as football sites routinely do. Do not alter them, combine them into your own branding or imply endorsement. Where attribution is requested by a source, include it clearly.

Caching is encouraged for performance and to reduce load, and it is consistent with display in your product. Keep cached data on your own infrastructure and serve it to your own users. Do not expose a cache as a public API for others to consume.

Protect the dashboard account that controls your keys with a strong password and multi-factor authentication where available. Limit who has access. A compromised dashboard account is worse than a single leaked key, because the attacker can create new keys.

Keys server-side only. One key per environment and service. Rotation documented and scheduled. Leak response rehearsed. Data displayed only in your own product. Images served through our media route. Trademarks used in context. Dashboard account protected. Review this list whenever you add a new service or team member.

Build pipelines often need a key for integration tests. Store it in the pipeline's secret store, mask it in logs, and use a dedicated key with access only to what tests need. Never print environment variables in build output for debugging; that habit has leaked more keys than any attacker. Pull requests from forks should not receive secrets at all, so design tests that can run against recorded responses when the key is unavailable.

Review pipeline logs occasionally for anything resembling a key. If you find one, rotate it, even if you think nobody saw it.

Treat preview deployments the same way. A temporary environment with a production key is a production risk with less monitoring.

A small publisher runs a website, a newsletter job and a staging site. Each has its own key named for its purpose. Keys live in the hosting platform's secret store. The newsletter key leaks when a contractor pastes a config file into a support forum. The editor spots it the same day, rotates the newsletter key from the dashboard, deploys the new secret, checks the usage page for unfamiliar calls and finds none. The website and staging keys are unaffected throughout, and the incident takes twenty minutes from discovery to close.

Afterwards, the team adds a note to their onboarding guide about never sharing configuration files, and schedules quarterly rotation for all three keys.