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 went live on 20 July 2026, meeting the Commission’s own Art. 13 deadline, and the implementing act adopted under Art. 13(5) sets out how registration works. So the requirements are no longer expectations: a published passport is registered with its unique identifier, the registration carries the resolver endpoint, and the registering platform keeps it in sync as passports are suspended or archived.

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 a backlog accumulated during an outage drains without a single passport falling through.

Two things stand between that and a battery registration succeeding today, and neither is ours to fix. The semantic catalogue a battery registration must reference is not yet defined, which blocks the registration path for everyone rather than for us specifically. And the registry caps a unique product identifier at 50 characters where ours runs to 65, with the identifier required to be a URL conforming to standards that must be purchased before that constraint can even be read properly. We would rather name both than describe a clean drain we cannot yet demonstrate.

Status

The registry integration is modelled and queued but not activated. What gates it now is not the registry’s existence — that question is settled — but the two blockers above, plus an enrolment process whose evidentiary requirements we are still confirming with the Commission rather than inferring.

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.