Move from RapidAPI to the release API.

The old v0 service remains a frozen bridge for existing RapidAPI users. Reep v1 is the launch API backed by the public release files at /api/v1. It is a new register, not a drop-in v0 ID continuity layer.

Request a v1 preview key API guide v0 archive

Key transition

Keep using RapidAPI keys against the old RapidAPI host during the bridge period.
Use direct Reep v1 keys through Unkey for /api/v1.
Send v1 requests with Authorization: Bearer <key>, not RapidAPI headers.
Migrate by provider IDs or release files. Do not assume old reep_... IDs map to new Reep IDs.

Endpoint Mapping

v0 endpoint	v1 path	Status
`GET /health`	`GET /api/v1/meta`	No exact health clone. Use metadata to verify release stamp and API readiness.
`GET /stats`	`GET /api/v1/meta`, `/coverage`	Counts now come from the release manifest and coverage page. Response shape differs.
`GET /search`	Not in launch API	Use CSV or DuckDB downloads for bulk search, or treat API search as a follow-up feature.
`GET /lookup?id=reep_...`	`GET /api/v1/entities/{reep_id}`	v1 accepts the new Reep IDs only. v0 IDs are not interchangeable.
`GET /lookup?id=Q...`	Not in launch API	Wikidata remains overlay/discovery context, not a launch lookup contract.
`GET /resolve`	`GET /api/v1/resolve/{provider}/{external_id}`	Supported with `namespace` and optional `type` query parameters.
`POST /batch/lookup`, `POST /batch/resolve`	`POST /api/v1/batch`	One unified endpoint: up to 100 items per request, each item typed `entity` or `resolve`, per-item `{status, body}` results so one miss never fails the batch.

  Resolve Example
 Old RapidAPI call:
 curl --request GET \
  --url 'https://the-reep-register.p.rapidapi.com/resolve?provider=transfermarkt&id=568177&type=player' \
  --header 'x-rapidapi-host: the-reep-register.p.rapidapi.com' \
  --header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY'
 New v1 call:
 curl -H "Authorization: Bearer $REEP_API_KEY" \
  "https://reep.football/api/v1/resolve/transfermarkt/568177?namespace=spieler&type=player"
 
  Customer Checklist
  Confirm which v0 endpoints and provider pairs the customer uses.
 Issue a v1 key for testing after the deployed smoke test passes.
 Check whether flat files or DuckDB are a better fit for bulk workflows, or move bulk lookups to POST /api/v1/batch.
 Record search needs as explicit follow-up work if they block migration.