Download the register. Use the API. Keep v0 separate.
Reep Next is released as downloadable public artefacts and as a keyed API.
The downloadable CSV release is the source contract; DuckDB is a convenience build;
relationship edges are optional; v0 remains frozen as an archive.
Last updated 20 July 2026 · release 20260720T235223Z ·
DuckDB 334 MB · 945,771 entities · cut on a weekly cadence.
Manifest.
Licence
Public domain: CC0 1.0
The open census is released under the
Creative Commons CC0 1.0
public domain dedication. You can use it for anything, including commercially. You may copy it,
adapt it, and redistribute it, with no permission needed and no attribution required.
A citation request, not a condition: if Reep is useful in your work, we'd
be glad if you credited it as “Reep, the football identity register (reep.football)” and
named the release stamp you used. This is a courtesy we ask for, never a term of the licence.
Bridge releases carry release-specific rights and provenance notes. CC0 can
waive only rights Reep holds; it does not grant rights in third-party source
material. Sponsorship and consultancy have separate terms but do not
change access to the public Register.
Download surface
Core CSV bundle
Entities, aliases, relationships, release metadata, and the public schema. In open-census mode, raw provider IDs and crosswalk files are omitted.
Relationship edges
Season, stage, team-season participation, affiliation, and succession edges ship today. Squad, lineup, and coach role-identity edges are on the roadmap. They will land as they clear the public-safety wall.
DuckDB convenience file
Generated from the same CSV export and smoke-tested. Useful for local analysis; not the only supported format.
Checksums and schema
Every release carries per-file checksums and schema metadata so consumers can verify and inspect before loading.
The DuckDB link always resolves to the current release's convenience
build; the file itself is per-release on R2 and CSV bundles are linked from the release manifest above.
Full raw CSV exports are not committed to git and Git LFS is not the default distribution path.
Cloudflare R2 Standard is the canonical launch host for large CSV and DuckDB files; GitHub is for docs, samples and small manifests.
Using the download
The file is a single DuckDB database, reep-register-v1.duckdb. Below: what it's for,
a two-minute primer, a prompt to hand your AI, and how it compares to the API. Every count is read
from the current release manifest, so it matches the file you download.
What it's mainly for: a crosswalk
Reep resolves football entities to stable Reep IDs and maps external provider IDs onto them. The
single most useful thing in the file is the bridges table
(provider, namespace, external_id, reep_id). Join your Opta, Transfermarkt or Wyscout
IDs to it and you get one stable identity, plus canonical names, aliases and relationships.
2,960,290Provider-ID bridges (the crosswalk)
945,771Resolved entities
372,144Typed aliases
925,160Relationship edges
452Competitions
11,886Teams
Full entity breakdown, provider roles and per-competition coverage live on
the coverage page. What's deliberately excluded (DOB, minors, raw evidence)
is in What is in scope below.
Hand it to your AI
Matching your data against the register is a good job for an AI assistant. This prompt gives it the
context (what the data is, what it's for) and tells it to ask you about your data and goal
first, rather than guessing your use case.
hover to preview
I've downloaded a DuckDB database from Reep, an open (CC0) football identity register. Before we do anything with it, read this context, then ask me questions.
What it is: Reep resolves football entities (players, coaches, referees, teams, competitions, seasons and matches) to stable Reep IDs, and maps external provider IDs (Opta, Transfermarkt, Wyscout and others) onto those IDs.
What it's mainly for: it is a crosswalk. Its most valuable use is reconciling football data that uses different providers' IDs into one identity, and enriching records with canonical names, aliases and relationships. Key tables:
- bridges(provider, namespace, external_id, reep_id): the provider-ID crosswalk
- entities(reep_id, entity_type, status, label): one row per resolved identity
- aliases(reep_id, alias, kind, rank, language): alternate/historical names for fuzzy matching
- relationships(from_id, to_id, kind): typed edges (team-season participation, affiliation, succession, …)
- redirects(old_id, reep_id): retired IDs mapped to their survivor; always resolve through this, never assume an ID has vanished
There is also an entity_search full-text index for name search.
Your first step: do not assume my use case. Ask me what data I have, which columns and provider IDs are in it, and what I'm trying to achieve. Once I've answered, propose an approach, help me load and query the file in DuckDB, join my data via the bridges table (falling back to alias name-matching where there is no provider ID), and flag ambiguous matches for me to confirm rather than guessing.
The file is reep-register-v1.duckdb, downloadable from https://reep.football/downloads .
Two-minute DuckDB primer
DuckDB is a single-file analytical
database. Think SQLite, but for analytics. No server: open the file and run SQL. Install the CLI
(brew install duckdb), the Python package (pip install duckdb), or query it
in the browser with DuckDB-Wasm. Then:
Open the file and list the tables
duckdb reep-register-v1.duckdb "SHOW TABLES;"
Map a provider ID to a Reep identity (the crosswalk)
SELECT e.reep_id, e.label, e.entity_type
FROM bridges b JOIN entities e USING (reep_id)
WHERE b.provider = 'transfermarkt'
AND b.external_id = '<their-id>';
Find an entity by name (aliases + languages)
SELECT reep_id, alias, language
FROM aliases
WHERE alias ILIKE '%vardy%';
The database is self-describing: SHOW TABLES; lists every table and
DESCRIBE entities; shows its columns. A machine-readable
schema and per-file
checksums ship with every release.
DuckDB or the API?
Both serve the same stamped register. The download is for whole-register work offline; the API is a
keyed, rate-limited convenience for single live lookups with automatic redirect resolution.
The first publishable bulk release carries resolved identity rows, labels, aliases, relationships, coverage and confidence. It excludes known minors and omits DOB, birth year, age fields, raw provider IDs and provider crosswalk files.
Rich DOB layer
The richer release is not public until the legal gate clears. When it launches, DOB is limited to active adult players and active adult coaches; retired people, referees, unknown-age rows and minors do not receive a DOB cell.
Open bridge register
Complete dated snapshots include every provider-ID bridge admitted by the field, rights and release gates. Sponsors sustain the public Register; consultancy and Loom work use separate customer-controlled inputs.
Corrections
Reports about wrong identity, DOB, status, missing rows or minor handling go through the public correction path and are resolved through the same gated register workflow.
API surface
The API is a manually issued, rate-limited convenience over the same stamped public Register. Keys and request
limits protect service reliability; they do not unlock additional fields or provider coverage. Use CSV or DuckDB
for bulk ingestion.
v0 remains available for existing customers during a separately managed migration. Reep Next launch does not
shut down or alter the RapidAPI service. v0 IDs are not promised to carry over to Reep Next.
Public methodology and reference material belongs in Reep Toolkit and the Handbook.
Partner-only material, local database paths, working datasets, and raw provider payloads are not public navigation.
Corrections and missing data should go through the public submissions path.
The public release does not include internal working notes, private issues, or provider payloads.
Reep Register