EU Central Registry

ESPR establishes a central registry operated by the European Commission as the authoritative directory of registered passports. The registry is one of the regulation’s structural mechanisms for letting authorities, recyclers, and market-surveillance bodies find a passport from a product without needing to know which platform issued it.

What the central registry is

The registry is a directory, not a store. It holds the mapping from product identifier (typically GS1 GTIN plus serial) to passport location (the issuing platform’s resolver endpoint). It does not hold the passport content. The content lives at the issuing platform; the registry just tells the world where to look.

This design is the right one because it lets the regulation centralise discovery without centralising data. The market-surveillance authority that needs to inspect a batch of textile passports queries the registry to find each batch’s resolver endpoint, then queries each resolver for the actual passport content. The registry does not become a single point of failure for passport content; it does become a single point of failure for discovery, which is a more tractable operational problem.

What the registry requires of implementations

The registry’s API is being defined at the time of writing. The expected requirements are: every published passport must be registered with the registry, the registration carries the product identifier and the resolver endpoint, the issuing platform must keep the registration in sync as passports are suspended or archived, and the platform must respond to registry health checks.

Odal has prepared for this beyond modelling the interface: every published passport already commits its registration intent to a durable outbox, in the same database transaction as the publish itself. A background worker drains that outbox with retry and backoff. The practical consequence: publishing never blocks on the registry, a crash never loses a registration, and the day the Commission’s API goes live, the accumulated backlog registers without a single passport falling through. (For context: the Commission’s own deadline to set up the registry was 19 July 2026; as of this writing, the API specification remains unpublished — so this durable-queue posture is not caution, it’s the correct engineering for the actual situation.)

Status

Activation of the registry integration is on the longer roadmap, contingent on the registry API being published. The interface is already modelled, so the implementation can land in days rather than months once the upstream API stabilises.

Why pre-investing in the bridge

Designing the central-registry interface before the registry exists is unusual, and it has a specific rationale. ESPR is a regulation in active definition, and the registry API is being co-defined with the implementation community (CIRPASS-2, the standards bodies, the early-mover platforms). Having a stable, opinion-bearing interface ready means the project can contribute to the API definition from a position of having already thought about the shape it wants the API to take. Showing up to the design conversation with an empty notebook is a worse position than showing up with a draft.

Read next

ESPR Overview — the framework regulation that mandates the registry. Standards & interoperability — the open standards a passport speaks.