EU Digital Product Passport API and Resolver Architecture

The ESPR requires the applicable product-group delegated act to specify the passport data, one or more data carriers, the carrier layout and position, whether the passport is at model, batch, or item level, the pre-contract access method, and which actors can access, create, or update which data. That means an API design should not begin by choosing a fashionable endpoint pattern. It should begin by recording which delegated-act fields, identifier granularity, access rights, and availability period the product group actually requires.

At the technical baseline, the passport must be connected through a data carrier to a persistent unique product identifier. The data carrier must be physically present on the product, packaging, or accompanying documentation as specified by the delegated act. Passport data must use open standards, interoperable formats, and be machine-readable, structured, searchable, and transferable through an open interoperable data exchange network without vendor lock-in.

A data carrier is the physical or machine-readable entry point. It may encode or expose a unique product identifier, a web link, or another standards-based identifier form selected by the applicable rules and standards. The resolver is the lookup component that turns the scanned or supplied identifier into the available passport links or data sources. Keeping those responsibilities separate makes it easier to change carriers, add a backup service, support batch lookup, or point different actors to different views without relabelling every product.

CIRPASS describes both HTTP URI and decentralized identifier approaches as architectural options, not as a binding mandate. Its user stories show the same core pattern: scan or receive a product identifier, obtain a usable URI or resolver endpoint, receive typed links for that identifier, select the relevant link, and request data from the data source with the credentials appropriate to the requester.

The ESPR registry is not the same thing as the public passport page or an operator's resolver. The Commission registry stores at least unique identifiers, and for products released for free circulation it stores the commodity code. The economic operator placing the product on the market or putting it into service uploads the registry data; the registry then communicates a unique registration identifier associated with the uploaded unique identifiers. That communication is expressly not proof of compliance.

The Commission web portal is a separate public search and-compare layer for data included in passports, constrained by the access rights set in delegated acts. Customs integration is another channel: customs authorities verify, at minimum, that the unique registration identifier and commodity code correspond to data stored in the registry, and the registry is to interconnect with EU CSW-CERTEX for automated customs-system exchange.

The ESPR requires free and easy access based on actor-specific rights, and it restricts rights to introduce, modify, or update passport data according to access rights specified in delegated acts. A useful architecture therefore marks each passport data element with audience, source, owner, update authority, verification status, and public or restricted presentation rules before it is exposed through any API.

Resolver flows should support anonymous public access for general passport information and credentialed access for actors such as authorities, recyclers, repairers, refurbishers, remanufacturers, and other relevant parties. CIRPASS examples describe credentialed requests for more refined data and update endpoints, while ESPR leaves the exact digital credential procedures to implementing acts. Avoid claiming that one token format, identity framework, or API style is legally required unless the relevant EU act or harmonised standard says so.

The safest public architecture statement is that the DPP must be interoperable, standards-based, searchable, machine-readable where appropriate, and transferable without vendor lock-in. It is not currently safe to state that every DPP must use REST, GraphQL, a specific decentralized identifier method, a specific barcode syntax, or a particular resolver implementation unless the product-group delegated act, harmonised standard, or adopted implementing rule requires it.

For engineering work, define replaceable interfaces: carrier decoding, identifier normalization, resolver lookup, typed-link selection, data-source retrieval, credential verification, field-level filtering, registry upload, portal/search feed, and audit logging. This lets a team test architecture assumptions now while preserving the ability to swap standards or sector choices later.

A DPP architecture review should produce evidence that a visitor, authority, customs user, or downstream circular-economy actor can follow from the physical product to the right passport data. The evidence should show the carrier value, identifier level, resolver response, source links, role-based filtering, registry upload state, and backup behavior for representative products.

The evidence file should also record open points. If a product group's delegated act has not yet specified exact carrier layout, data fields, access rights, or passport level, state that as an implementation dependency rather than filling the gap with unsupported dates, thresholds, or protocol requirements.

The review should explicitly validate the update and recovery scenarios that visitors would expect to see in the full architecture: repairer updates, independent refurbisher handover, recycler reporting, remanufacturer replacement of the original passport, and fallback to a backup or archive after operator insolvency.