Player Data

Player statistics are the one part of the API that is off by default. This page explains why, how to turn it on, and exactly what is and is not published when you do.

It is off until you turn it on

Results, standings, fixtures and teams are about matches. Player statistics are about identifiable people, so publishing them is a decision each organisation makes deliberately rather than something that starts happening because a key exists.

Until you enable it, /v1/players answers 200 with an empty list and says so:

{
  "success": true,
  "message": "Player statistics are not enabled for this organisation",
  "data": []
}

Turning it on

Go to Settings → Integrations and enable Player statistics. It applies to the whole organisation and to every key, not per key. Changing it takes effect on the very next request — there is no cache to wait out in either direction.

Switching it back off stops player data immediately and completely. Nothing else is affected: your results, fixtures, teams and standings keep serving normally, and your keys keep working.

Changing this setting needs the Manage integrations permission — the same bar as creating a key, because it is the same kind of decision about data leaving the platform.

What is published

Enough to identify a player on a public page, and nothing more:

• Name — as it appears on your team sheets.
• Profile picture — if the player has uploaded one.
• Country — if recorded, otherwise null.
• A stable player UID, so you can link a player across seasons.
• Match statistics — appearances, scoring and the rest, per sport.

What is never published

The following never appear in any API response, whether or not player statistics are enabled:

• Email addresses and phone numbers.
• Dates of birth and any age derived from one.
• Home addresses and emergency contacts.
• Account, payment and billing details.
• Internal record numbers of any kind.

This is enforced by the response contract rather than by filtering: each endpoint builds its response from a fixed list of permitted fields, so a value can only reach you if it was explicitly named. Adding a column to a player record does not quietly add it to the API.

Before you switch it on

Publishing player names and statistics to your own site is a normal thing for a league to do, and it is what most clubs want. It is still worth a moment's thought:

• Junior players. Consider whether names and photographs of children should be on a public page, and what your own safeguarding policy says.
• Tell your members. People who signed up to play may not expect their statistics on a public website. A line in your privacy policy or a note at registration covers it.
• Remember where the key runs. A key in front-end JavaScript makes this data readable by anyone who views source, not only by your page.
• It is reversible. Switching the toggle off stops it immediately, but anything already copied by a site you do not control is out of your hands.

Handling it in code

Treat an empty list as a valid state rather than an error, so your page degrades gracefully if the toggle is ever turned off:

const response = await fetch("https://api.scored.app/v1/players", {
  headers: { "X-Api-Key": process.env.SCORED_API_KEY },
});

const { data, message } = await response.json();

if (!data.length) {
  // Either the org has not opted in, or there are genuinely no players yet.
  // message distinguishes the two.
  return renderWithoutPlayerStats();
}

return renderPlayerTable(data);