EU Digital Product Passport registry and web portal integration
Design DPP integration around the ESPR architecture: a decentralized passport, a Commission registry for identifiers, and a public that respects delegated-act access rights.
The became operational on 20 July 2026. Use the official registry interface, API documentation, and applicable product law for registration; do not treat registration as product approval.
The EU Digital Product Passport uses three separate layers: the product-facing data carrier and resolver, the decentralised passport store operated by the responsible economic operator or a service provider, and EU-level discovery and enforcement services. The Commission's became operational on 20 July 2026 and stores identifiers, registration data, and high-level metadata rather than the full passport. The statutory Article 14 is a separate search-and-comparison service that must respect product-group access rights.
1
Section 1
What the ESPR registry does, and what it does not prove
Article 13 of Regulation (EU) 2024/1781 requires a Commission registry that stores at least unique identifiers. For products intended for release for free circulation, it also stores the commodity code. The Registry became operational on 20 July 2026. Commission Implementing Regulation (EU) 2026/1778, which enters into force on 6 August 2026, sets its practical arrangements, including access management, user verification, data registration, storage, and technical architecture.
After upload, the registry returns a 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.
For the general ESPR registration route, a may register a DPP or correct an existing registration. A verified value-chain actor may perform Registry actions only where the applicable Union law permits that role. Under Implementing Regulation (EU) 2026/1778, from 6 August 2026 verified status ends when the actor's electronic identification means expire and in any event after three years; the actor must repeat verification before it can register or modify data again.
Keep a registry payload map next to the DPP data model: the identifiers and metadata required by the applicable law, the commodity code for release-for-free-circulation cases, and the returned registration identifier. Keep the full passport in the decentralised passport system unless the applicable delegated act or other Union legislation requires additional registry data. Do not assume that every Annex III field belongs in the registry.
Register at the granularity required by the applicable law. For an item-level DPP, also link the corresponding batch and model identifiers when those designs exist; for a batch-level DPP, link the model identifier when a model design exists. Unique-by-nature products such as handmade goods do not need nonexistent batch or model identifiers. If several Union laws require different levels for the same product, register at the most granular level.
Registry data should be versioned separately from public passport content because a registry acknowledgment is not a compliance certificate.
Customs-facing products need a reliable join between the , the commodity code, and the passport record used by import or logistics workflows.
Calendar the operator's identity-verification expiry and repeat verification before the electronic identification means expire or the three-year maximum is reached.
Treat automatic validation as a structure and completeness gate: it checks at least the data structure and granularity and, where relevant, commodity codes and the backup-provider link. Market-surveillance authorities assess substantive correctness.
Use the live Registry user interface or API and the current Commission user guide for submission mechanics; keep test-environment records separate from live registrations.
Supports the registry purpose, the unique registration identifier, the customs commodity-code link, and the warning that registry communication is not proof of compliance.
That communication by the registry shall not be deemed to be proof of compliance
Current official operating source for registry scope, enrolment, live and test environments, registration functions, and the economic-operator user guide.
Binding implementation arrangements for the DPP Registry, including the three-year verification maximum, model/batch/item registration links, unique-product exceptions, automatic structural validation, proof of registration, storage, and technical architecture.
Recommended next step
Validate your DPP registry and portal architecture
This guide helps check whether your identifiers, data carriers, resolver paths, access controls, service-provider backup, and registry evidence are ready for product-group DPP rules.
How to connect identifiers, data carriers, and resolver paths
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 symbols, and passive or active radio-frequency tags, 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.
Model-level passports fit shared characteristics; batch-level passports fit batch traceability; item-level passports fit individualized lifecycle changes such as repair, refurbishment, or recycling updates.
Encode only the durable identifier or resolvable link that the data carrier can support reliably; store richer and updateable passport data online or in the controlled DPP system.
Test lookup paths for scan readability, URL resolution, language fallback, access-control routing, and broken-link recovery before placing a product on the market.
Supports online lookup and persistence considerations for DPP information reached through a data carrier.
3
Section 3
Access categories for public users, value-chain actors, authorities, and customs
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 required by Article 14 is a publicly accessible search-and-comparison layer for DPP data, but search results must follow the access rights in the applicable delegated act. Do not confuse that statutory portal with the Commission's July 2026 DPP information website or with an operator's own public passport page.
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.
Public access: customer-facing information that the delegated act makes public, reachable without unnecessary login or personal data collection.
Value-chain access: supplier, repair, refurbishment, remanufacturing, recycling, or dealer data that may require authenticated roles and scoped update rights.
Authority access: market surveillance, customs, Commission, or competent national authority views needed for legal duties, risk management, and controls.
Editorial access: internal and service-provider permissions for introducing, modifying, or updating passport data under Article 11 access-right restrictions.
Supports the need to balance broad accessibility with restrictions for business confidentiality, privacy, and trade secrets.
4
Section 4
DPP service-provider controls to specify before integration
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 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 limits on selling, reusing, or processing passport data. ESPR permits processing beyond what the service needs only when 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.
Require a tested backup and recovery process for every passport record linked to placed-on-market products.
Require exportable, structured, machine-readable data and a documented migration path to another provider.
Separate provider administrator rights from business update rights for product, supplier, repair, and authority-facing data.
Track whether the provider is hosting the main DPP, the backup copy, resolver services, access control, or only a subset of those functions.
Supports backup-copy obligations, DPP service-provider limits, data availability after cessation events, and the open interoperable design requirement.
make available a back-up copy of the digital product passport
5
Section 5
Implementation checklist for registry and portal readiness
Review this checklist before committing to a DPP platform, public portal pattern, or product-label data carrier. Registry mechanics now have official implementation rules and a live environment. Product-group field lists, access rights, application dates, and the Article 14 search-and-comparison portal still require separate tracking.
Link 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.
Confirm whether the relevant delegated act requires a DPP at model, batch, or item level and which passport fields are mandatory for the product group.
Choose the unique product identifier, operator identifier, and facility identifier approach using internationally recognised standards or the applicable harmonised/common specifications when available.
Select the data carrier for the physical product context, then test scanning, fallback text, packaging/document placement, accessibility, and durability.
Build a resolver or lookup endpoint that can return public data without unnecessary friction and restricted data only to authenticated actors with the right access category.
Keep registry upload fields and the returned in a controlled system linked to customs and import workflows where relevant.
Contract for DPP service-provider backup, recovery, migration, security, privacy, and data-use restrictions before relying on the provider for placed-on-market products.
Record open items separately when the fact depends on a future delegated act, implementing act, harmonised standard, or Commission portal specification.
Supports the DPP requirements that should be tracked in an implementation evidence file: identifiers, data carriers, access rights, provider backup, registry upload, and web portal access.
machine-readable, structured, searchable, and transferable
Supports GS1 identifier, data-carrier, and Digital Link implementation considerations when teams choose GS1-based product identification and scan-to-web patterns.
Source for practical DPP design topics, including data carriers, information portals, identifier decisions, public and restricted data, and DPP setup guidance.
Supports practical DPP design choices for information portals, identifier selection, data-carrier options, and model, batch, or item passport levels.
Supports separating public DPP data from restricted data controlled through user roles and authentication.
Show 1 more
Supports practical design checks for identifier selection, data-carrier selection, portal setup, and information-exchange management.
"Guidelines to create a Digital Product Passport"
More quoted passages
"data carrier, information portal contents, and information exchanges"
"public data should be available without requiring any logins"
Current binding Registry rules for verification, registration granularity, higher-level identifier links, automated validation, and operator responsibilities.
Binding implementation arrangements for the DPP Registry, including the three-year verification maximum, model/batch/item registration links, unique-product exceptions, automatic structural validation, proof of registration, storage, and technical architecture.
Current operational source for organisation enrolment, live and test environments, registration channels, and the economic-operator user guide.
Current official operating source for registry scope, enrolment, live and test environments, registration functions, and the economic-operator user guide.
Reference source for GS1 identifier and data-carrier patterns, including GS1 Digital Link URI usage for scan-to-web product information.
Supports GS1 identifier, data-carrier, and Digital Link implementation considerations when teams choose GS1-based product identification and scan-to-web patterns.
Primary legal source for ESPR DPP requirements, including data carriers, unique identifiers, access rights, service providers, the registry, the web portal, and customs controls.
Supports the DPP requirements that should be tracked in an implementation evidence file: identifiers, data carriers, access rights, provider backup, registry upload, and web portal access.
"Web portal for data in the digital product passport"
More quoted passages
"machine-readable, structured, searchable, and transferable"
Supports backup-copy obligations, DPP service-provider limits, data availability after cessation events, and the open interoperable design requirement.
"make available a back-up copy of the digital product passport"
Supports the registry purpose, the unique registration identifier, the customs commodity-code link, and the warning that registry communication is not proof of compliance.
"That communication by the registry shall not be deemed to be proof of compliance"