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 and interoperable formats and, as appropriate, be machine-readable, structured, and searchable; it must be 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 live Commission Registry is not the public passport page or an operator's resolver. It indexes DPPs through unique identifiers, registration data, and high-level metadata while the detailed passport remains decentralised. Implementing Regulation (EU) 2026/1778, effective from 6 August 2026, provides a secure user interface and API for registration, a verification platform, identity and authorisation controls, unique registration identifiers, a semantic repository, and logs.

The Commission web portal remains a separate search-and-compare layer constrained by product-specific access rights. Customs integration is another channel: for covered products, customs checks match the unique registration identifier and commodity code to Registry data. Automated Registry validation checks structure and completeness; market-surveillance authorities remain responsible for substantive correctness.

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 binding baseline is that the DPP must be interoperable, standards-based, and transferable without vendor lock-in and, as appropriate, machine-readable, structured, and searchable. Commission Implementing Decision (EU) 2026/1736, in force from 15 July 2026, cites EN 18216:2026 for data exchange protocols, EN 18219:2026 for unique identifiers, EN 18220:2026 for data carriers, EN 18221:2026 for storage, archiving and persistence, EN 18222:2026 for lifecycle-management and search APIs, and EN 18223:2026 for system interoperability.

A DPP that conforms to a cited standard is presumed to conform only with the ESPR Articles 10 and 11 requirements that standard covers. The decision does not make REST, GraphQL, a specific decentralised identifier method, a specific barcode syntax, or one resolver pattern universal. Check the standard's scope, the applicable product rule, and any implementing act before describing a technical choice as required.

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.