EU Digital Product Passport registry and web portal integration

Article 13 of Regulation (EU) 2024/1781 requires the Commission to set up a digital registry that stores at least unique identifiers. For products intended for release for free circulation, the registry also stores the commodity code. The economic operator placing the product on the market or putting it into service uploads the required registry data.

After upload, the registry returns a unique registration identifier associated with the uploaded identifiers for the specific product. ESPR is explicit that this communication is not proof of compliance with ESPR or other Union law, so implementation records should not treat registration as a substitute for conformity assessment, technical documentation, or product-group passport content.

The practical integration pattern is to keep a registry payload map next to the DPP data model: product identifier, operator identifier, facility identifier where applicable, commodity code for customs scenarios, service-provider reference for the backup copy, and the returned registration identifier. Keep the full passport content in the decentralized passport system unless a delegated act or implementing act requires a specific field to be stored in the registry.

A DPP integration should start with the identifier level that the applicable delegated act requires: product model, batch, or item. ESPR requires passport data to refer to the product model, batch, or item specified in the delegated act, and Annex III lists data elements that can include the unique product identifier, GTIN or equivalent identifiers, commodity codes, compliance documentation, operator identifiers, facility identifiers, and the reference to the DPP service provider hosting the backup copy.

The data carrier is the physical entry point. ESPR requires it to be physically present on the product, packaging, or accompanying documentation as specified in the delegated act. CEN-CENELEC guidance describes common options such as QR codes, DataMatrix, NFC, RAIN RFID, and BLE, while ETSI notes that online information is commonly reached through a web link obtained from a data carrier.

For resolver design, use the data carrier to resolve to the passport record or a controlled landing endpoint, then route by identifier, actor credentials, language, market, and access category. The resolver should be stable for the expected product life and should not depend on a single campaign URL or CMS page that may be retired before repairers, recyclers, customs authorities, or customers need it.

ESPR does not make every passport field public. Article 11 requires free and easy access based on the access rights set in the applicable delegated act for customers, manufacturers, importers, distributors, dealers, repairers, refurbishers, remanufacturers, recyclers, market surveillance authorities, customs authorities, civil society organisations, trade unions, and other relevant actors.

The Commission web portal required by Article 14 is a public search and comparison layer for data included in digital product passports, but it must operate consistently with those access rights. That means teams should design public, restricted, authority, customs, and editor/update roles before choosing a portal vendor or publishing flow.

CEN-CENELEC guidance aligns with this split: public data should be available without requiring logins or personal data collection, while restricted data can be controlled through software roles, login, or other authentication. Avoid using customer personal data as a portal shortcut; ESPR states that customer personal data must not be stored in the DPP without explicit GDPR-compliant consent.

ESPR requires the economic operator placing the product on the market to make a backup copy of the DPP available through an independent third-party DPP service provider. It also allows the passport to be stored by the responsible economic operator or by DPP service providers.

A provider contract should therefore cover more than hosting. It should identify the backup-copy scope, data retention period from the delegated act, recovery obligations after insolvency or cessation of activity, data export format, authentication responsibilities, security controls, incident handling, and how the provider will avoid selling, reusing, or processing passport data beyond what is necessary for the storage or processing service unless the economic operator specifically agrees.

Because the Commission may adopt provider requirements, certification rules, and digital-credential procedures, procurement should keep these obligations adaptable. Avoid locking the passport into a vendor-only identifier, proprietary resolver, or data model that cannot be moved into an open interoperable exchange network.

Use this checklist before committing to a DPP platform, public portal pattern, or product-label data carrier. It is intentionally limited to integration decisions supported by ESPR and current standards guidance; final Commission portal mechanics should be tracked separately when official implementing material is available.

The strongest evidence file links each public claim and technical decision to a product group, delegated-act requirement, identifier scheme, data-carrier test, resolver result, access-control rule, provider contract, and registry upload status.