Reep · the football identity register
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.
This release 2026-07-20 23:52Z · live API at /api/v1.
Live demo
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
The competition identity shared across provider competition IDs.
rlceee8c6f01551dEnglish Premier League, not every provider label that happens to say "Premier League".
The problem
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
Reep does not carry
Who it helps
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
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.
Clubs and companies
Use Reep IDs as the spine between scouting tools, CRM or ERP systems, historical datasets and feed-provider integrations.
Data providers
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.
How Reep thinks
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.
The obvious check, matching on name plus date of birth, breaks on the cases that matter most: real people who genuinely share both.
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.
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.
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 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.
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.
Many providers resell the same upstream feed. Three brands agreeing looks like strong corroboration, but it can be one opinion repeated three times.
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.
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.
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.
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.
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.
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.
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.
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.
Clubs relocate, dissolve, refound or split; the real-world identity can change even when the name barely does.
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.
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.
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.
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.
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
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
Look up by Reep ID or provider bridge and get the current release stamp with the response.
Downloads
Use canonical CSVs and the analyst bundle when you want reproducible local joins.
Coverage
See public counts, provider roles, known gaps and aggregate provider finding counts.
Corrections
Reports and file drops enter review. They do not mutate the register directly.
Reep Register