The Reep Register

Reep · the football identity register

One ID for every football entity.

A stable Reep ID for football's players, teams, coaches, competitions, seasons, stages and matches, mapped to the provider IDs people already use.

Reep joins public datasets, internal systems and commercial feeds so no one has to rebuild this matching from scratch. What we publish is a checked copy of the register: stable IDs, provider bridges, aliases, selected relationships, coverage details, and a way to report anything wrong.

Explore a live record Use the API Download data Coverage Send a correction

This release 2026-09-03 12:39Z · live API at /api/v1.

1,876,913 entities
6,058,988 provider bridges
484,816 aliases
1,900,064 relationships
56 data providers
Bridged across api_footballbesoccercapologyclubeloeafcespnfbreffbref_dsgfifafmjleaguenational_football_teamsoptarsssfscisportssecond_spectrumskillcornersoccerdonnasportmonksstatsbombtransfermarktuefaunderstatwyscoutfootballdatabase_euplaymakerstatsworldfootball11v11bdfutbolhugmankickerkooorapremier_leaguesoccerbasesoccerwaysofascorestatmuse_pleu_football_infoas_combdfaflashscorelapreferentefootballfaktsfussballdatengerman_fafotbolltransferslequipefff_frninetyminutmackolikdongqiudiglobal_sports_archiveopta_numericserie_afoot_resultatswikidata see each provider's role on the coverage page →

First official data partner

SkillCorner asked for an outside view of its identity metadata, then acted on it.

In July, SkillCorner did something most data companies leave in-house. It opened its player and team registry to an independent check. Not the tracking data or physical outputs it sells, but the identity metadata underneath: the names, dates of birth and identifiers that decide which player a row of tracking belongs to. Every provider resolves that layer on its own, and none has an outside view of where it drifts.

Read the case study Read SkillCorner's announcement

What Reep brought was cross-provider triangulation: because their register resolves the same entities from several independent sources, they could point us at specific records rather than general suspicions.

Mohamed Rahmouni, Data Product Manager, SkillCorner
853 → 102
duplicate name-and-birthday groups
811
dates of birth corrected
0
new duplicates created

Live demo

A real football spine, with IDs attached.

Click through the example. Each node is a real entity from the generated public register export; the side panel shows the Reep ID and provider bridge IDs currently attached to that entity.

Click any node to inspect its record

competition

Premier League

competition

The competition identity shared across provider competition IDs.

rlceee8c6f01551d

English Premier League, not every provider label that happens to say "Premier League".

English Premier LeagueBarclays Premier LeagueFA Barclaycard PremiershipFA Barclays PremiershipFA Carling Premiership
opta competition:2kwbbcootiqqgmrzs6o5inle5
opta competition_numeric:8
transfermarkt wettbewerb:GB1
wyscout competition:364
espn league:eng.1
api_football competition:39
skillcorner competition:1

The problem

Football data is scattered across systems that do not agree on IDs.

A player in one feed, a team in another and a match in a third can refer to the same real-world thing without sharing a key. Reep is the shared identity layer: a stable register that maps provider IDs onto football entities and records where the evidence is strong, weak or still under review.

Reep carries

  • Stable Reep IDs for competitions, seasons, stages, teams, players, coaches, referees and matches.
  • Provider bridges as namespace-scoped IDs, never bare external IDs.
  • Aliases and selected public-safe facts where the release policy allows them.
  • Relationship rows that show how entities connect: season, stage, match, team and person context.
  • Redirects, release stamps, checksums and coverage metadata for reproducible use.

Reep does not carry

  • Raw provider mirrors, fetch recipes or credentials.
  • Event feeds, scouting grades, xG, tracking data or tactical metrics.
  • Private review evidence, operator notes or source packets.
  • Uncleared personal data or provider-derived fields outside the public policy.

Who it helps

One register, different jobs.

Reep is useful whether you are joining public files in a notebook, running data infrastructure inside a club, or helping customers connect your provider IDs to the rest of their stack.

Individuals and researchers

Join public football datasets without maintaining one-off crosswalks.

Resolve a Transfermarkt player ID to a Reep ID, join that to a public CSV, cite the release stamp, and keep your notebook stable when provider pages move.

Download CSVsUse the APIFollow redirects between releases

Clubs and companies

Outsource the boring, risky part of entity resolution to a dedicated register.

Use Reep IDs as the spine between scouting tools, CRM or ERP systems, historical datasets and feed-provider integrations.

Reduce vendor-specific glue codeDedupe players and teamsSubmit corrections into the review workflow

Data providers

Make your IDs easier for customers to integrate with everyone else.

Share provider IDs or mappings with Reep, attach clean bridges where evidence clears the gate, and receive private correction notices for duplicates, stale IDs and coverage anomalies.

Improve discoverabilityReceive provider noticesHelp customers resolve IDs faster

How Reep thinks

Common football ER traps, handled deliberately.

The public release does not expose the private provider substrate, but the approach is not magic. Reep combines ordinary matching ideas with football-specific structure: competitions, seasons, stages, teams, careers, names, roles and provider independence.

Same name, same birth date

Problem

The obvious check, matching on name plus date of birth, breaks on the cases that matter most: real people who genuinely share both.

Reep approach

Reep never treats a name and a date as proof. Records that agree on them are candidates. Who a player actually lined up with, for which club and in which season is what settles it. When even that is ambiguous, the case waits for a human rather than guessing.

Example

Identical twins Filip and Patrik Twardzik were both born on 10 February 1993. A third-party crosswalk, matching on name and date, linked a record to the wrong brother. Their different clubs and line-ups are what tell them apart.

Structure beats the string

Problem

A provider’s own database can carry the right biography and the right line-ups under the wrong player’s name. In that case, matching on the name is not merely unreliable; it is confidently wrong.

Reep approach

Reep resolves people from structure, not text: the same match, the same side, the same shirt number across many games. A name is an attribute attached afterwards, never the thing the match is built on.

Example

One major source filed a real player’s exact birth date, nationality and shirt-verified appearances under a completely different person’s name. Reep matched on the appearances and reached the right human; the wrong name was flagged as untrusted, not followed.

Count independent voices, not logos

Problem

Many providers resell the same upstream feed. Three brands agreeing looks like strong corroboration, but it can be one opinion repeated three times.

Reep approach

Reep groups providers into independence buckets. Sources that share an upstream feed count once. Reep admits an entity only on genuinely independent agreement. Where independent sources disagree, it stays honestly uncertain instead of siding with the loudest.

Example

A player’s birth date was “confirmed” by three sources against one dissenter. The three all resold a single provider’s feed, and the lone dissenter was right. Reep held the conflict open until a sourced correction settled it, rather than trusting the majority of logos.

An ID needs its namespace

Problem

A provider can reuse the same external ID in different namespaces. Treating the raw value as globally unique can silently fuse unrelated entities or roles.

Reep approach

Every Reep bridge is provider plus namespace plus external ID, resolving to exactly one entity. The raw number is never a join key on its own.

Example

For example, Transfermarkt spieler 11234 and trainer 11234 are different identifiers because spieler and trainer are different namespaces. Reep preserves them as transfermarkt:spieler:11234 and transfermarkt:trainer:11234.

Teams need their football world

Problem

City, United, Real and Sporting are common names across reserve sides, academies and women’s teams. A club name alone produces confident false matches, including across genders.

Reep approach

Team resolution is scoped by country, gender and competition, and a deterministic guard refuses to attach a provider ID whose gender or country disagrees with the entity it would join.

Example

A men’s club and its women’s side can share a name to the letter and still be different entities in different competitions. Reep keeps them distinct and records the relationship, rather than collapsing them into one team that appears to play in two leagues at once.

Lineage is not identity

Problem

Clubs relocate, dissolve, refound or split; the real-world identity can change even when the name barely does.

Reep approach

Reep keeps separate entities where the entity genuinely changed, then records succession or affiliation between them. This preserves continuity you can follow without using a merge that erases it.

Example

Wimbledon FC, MK Dons and AFC Wimbledon are bound by history but are not one club. Reep links them; it does not collapse them into a single row.

People change names

Problem

A player can appear under an earlier name and a later one across two provider IDs. From the outside, this looks exactly like two different people who happen to share a birth date.

Reep approach

The deterministic guard refuses to auto-merge two same-name, same-date records. Only genuinely new evidence, such as a career that runs unbroken across both IDs, closes the case on the record.

Example

One player appears as “Saad Morsli” under an earlier provider ID and “Saad El Morsli” under a later one, with the same birth date. Their appearances run continuously from one ID to the next with no overlap. One career and one person authorise the merge.

Use it

Start with the shape that fits your workflow.

Query the current release through the API, download flat files for local analysis, inspect coverage, or submit a correction that can be folded into a future release.

API

Resolve IDs at runtime.

Look up by Reep ID or provider bridge and get the current release stamp with the response.

API docs →

Downloads

Work locally from files.

Use canonical CSVs and the analyst bundle when you want reproducible local joins.

Downloads →

Coverage

Check the current release.

See public counts, provider roles, known gaps and aggregate provider finding counts.

Coverage →

Corrections

Tell us what is wrong.

Reports and file drops enter review. They do not mutate the register directly.

Submissions →