On 20 July 2026, the European Commission put the Digital Product Passport Registry and its testing environment into operation. An abstract component of the ESPR architecture has therefore become a system that companies can actually test. The most important distinction for manufacturers is simple: the Registry is the central index, while the product passport itself remains decentralised.
What became operational on 20 July
The Registry stores unique product identifiers, registration data and selected high-level metadata. The full product information remains with the responsible economic operator or an appointed DPP service provider. The Commission consequently describes the Registry as an indexing service, not as a central content-management system.
Registration is available through a secure user interface and an API. Companies can also obtain secure electronic proof of registration. This matters in B2B processes because suppliers and customers can demonstrate that a passport has been registered in the EU system without copying the complete data set.
The launch is not limited to product groups governed by ESPR delegated acts. The Commission also identifies batteries, construction products, toys, detergents and end-user surfactants where the relevant Union legislation requires a DPP. The first binding deadline remains 18 February 2027 for certain batteries.
Registry, resolver and data source are three separate layers
A robust DPP system should keep their responsibilities clear:
- The EU Registry confirms that an identifier and the required metadata have been registered.
- A resolver directs the persistent product identifier to the appropriate resource.
- The underlying data source supplies current information for people and machines.
This separation is not cosmetic. Storing all data on a proprietary product page does not create a Registry integration. Conversely, registering an identifier does not provide a useful product passport. Both sides have to be linked through stable identifiers.
An open, persistent link is suitable for resolution. A GS1 Digital Link resolver can expose different representations behind the same identifier: a human-readable page, machine-readable JSON-LD or supporting documentation. The physical data carrier can remain stable while the connected systems evolve.
What companies should test now
The testing environment should be treated as more than a manual click-through. It is a pre-production integration environment.
Organisation and roles
Determine which legal entity registers, who represents it in the system and which teams may create or update registrations. Master-data, compliance and IT teams may all be involved, along with an external service provider. A personal test login is not a substitute for a production role model.
Identifiers and granularity
The product team should understand whether a passport will apply at model, batch or item level. The answer depends on sector-specific law. The Registry test is the right moment to map internal product IDs, GTINs, batch identifiers and the externally used persistent identifier.
API and repeatability
A production process needs more than one successful POST. Registration, updates and error handling must be repeatable and auditable. This includes idempotent requests, technical receipts and an unambiguous relationship between the ERP record, DPP and Registry entry. An API-based DPP process reduces manual variation when products are created at scale.
Separation of metadata and product data
Registry metadata should not become a second master-data system. Define which fields belong in the Registry and which remain in the decentralised passport. Every field needs one authoritative source, an owner and an update rule.
Evidence and monitoring
Store proof of registration together with the timestamp, identifier and system response. Monitoring should then answer three questions: does the Registry entry exist, does the resolver work and do Registry metadata still match the product status?
Why customs need an end-to-end test
The Registry helps customs authorities verify electronically whether imported products have a valid registered DPP and whether the required commodity code was provided before release for free circulation. Importers therefore gain a new dependency: the product identifier, Registry entry and customs declaration must be consistent.
An error may affect the border process rather than only a public product page. Companies should simulate the path from product creation to import documentation and decide who is authorised to correct a faulty registration quickly.
A practical 30-day testing plan
- Select one real legal entity and a small, representative product set.
- Document the intended DPP granularity and authoritative identifiers for each product.
- Complete one end-to-end registration through the user interface and, where relevant, the API.
- Archive the registration proof, resolver response and machine-readable product data together.
- Test failure cases: duplicate identifier, stale metadata, unavailable data host and withdrawn product.
- Turn the findings into an operating model with responsibilities, monitoring and escalation paths.
The Registry becoming operational does not mean that every sector-specific data obligation already applies. It does, however, move the discussion from presentations to observable workflows. Companies can now test whether their identifiers, roles and APIs fit together before the first mandatory dates arrive.
