The Reep Register

API

Partner preview of the release API.

Public consumption starts with the complete stamped downloads. The Reep Next read API is initially restricted to named data partners and Loom consultancy engagements while its query shapes and operating costs settle. It does not expose data unavailable in the public release.

Release

Current stamp: 20260907T201034Z

Schema: public-bridge-register-v2

Every response includes `X-Reep-Release-Stamp` when release metadata is available.

Auth and limits

Use Authorization: Bearer <key>. Metadata endpoints cost 0 lookups; search, entity, bridge, overlay, relationship and resolve endpoints cost 1 lookup (returned as X-Reep-Credits-Remaining) and use the key’s Unkey rate limit.

Preview keys are issued manually and initially carry 1,000 lookups per month at 2 requests per second. These limits protect the service; they are not paid data tiers. Use the stamped downloads for bulk ingestion.

Entity and resolve responses are core-only unless you add include=aliases,attributes,bridges,relationships,overlay.

Search by name

curl -H "Authorization: Bearer $REEP_API_KEY" \
"https://reep.football/api/v1/search?q=salah&type=player&sort=bridges&limit=10"

Search covers canonical labels and safe aliases. Relevance is the default order; sort=bridges orders by public bridge coverage. The endpoint is bounded to 500 candidates per token, so use the DuckDB FTS index for exhaustive local discovery.

RapidAPI migration

The old v0 RapidAPI service stays frozen during the bridge period. v1 keys are direct Reep keys, and v0 Reep IDs are not interchangeable with the new Reep IDs.

Read the endpoint migration guide.

ID stability

Reep IDs are append-mostly: an ID we have published never silently vanishes. When identities merge, the losing ID returns its survivor via redirected_to (with requested_id echoed back); retired IDs resolve to a tombstone. Design your storage around the redirect, not string equality.

Read the full ID stability policy.

Bulk lookups

curl -X POST -H "Authorization: Bearer $REEP_API_KEY" \
-H "Content-Type: application/json" \
-d '{"include":["bridges"],"requests":[{"type":"resolve","provider":"transfermarkt","external_id":"28003"},{"type":"entity","id":"rl0057d821203c1a"}]}' \
"https://reep.football/api/v1/batch"

Up to 100 entity/resolve items per request return per-item {status, body} results, so one miss never fails the batch. Each item costs 1 lookup; the batch counts as a single request against the rate limit. Also see providers and the OpenAPI spec.

Resolve a provider ID

curl -H "Authorization: Bearer $REEP_API_KEY" \
"https://reep.football/api/v1/resolve/api_football/340?namespace=competition&type=competition&include=overlay"

What changed since your last sync

curl -H "Authorization: Bearer $REEP_API_KEY" \
"https://reep.football/api/v1/changes/summary?since=<stamp>"

Every release ships its changelog against the previous one: entities added, IDs redirected (with the survivor), and provider bridges added or removed per entity. /changes/summary returns the counts for a window - the cheap poll; /changes pages the events, filtered by type or provider, with from/to for any two published releases (/changes/releases lists them). No lookup cost, and an ETag so a matching If-None-Match is a free 304. Your current stamp and its predecessor are in release metadata.

Fetch an entity

curl -H "Authorization: Bearer $REEP_API_KEY" \
"https://reep.football/api/v1/entities/rl0057d821203c1a?include=bridges,aliases,relationships,overlay"

Wikidata appears under overlay.wikidata with lower-confidence aliases and inherited-ID hints; it is not returned as a canonical bridge.

Fetch overlay only

curl -H "Authorization: Bearer $REEP_API_KEY" \
"https://reep.football/api/v1/entities/rc000d9d641fc253/overlay"