On 30 October 2026 the European Commission (DG GROW) published the complete technical documentation, version 1.0, for the EU Digital Product Passport Registry. Six documents are now available on the Commission's resources and documentation page for the Digital Product Passport:

  • the API Integration Guide
  • the OpenAPI Specifications (OpenAPI 3.1)
  • the Semantic Data Guide
  • the Semantic Data Artifacts (78 files, EUPL-1.2 licence)
  • the Service Account Integration Guide
  • the Self-Hosted Authentication Guide

This closes a long gap. The legal framework was known, but the technical layer connecting operators to the Registry was missing. It is now published and versioned, so builders can integrate against definitive specifications. The first product group covered is batteries, with subgroups for electric vehicle, industrial and light means of transport batteries.

The registry is an index, not an archive

The central design choice is simple. The Registry is a central index. It records identifiers and metadata for each passport. The full passport data stays hosted by the economic operator or by the service provider the operator designates.

When a passport is registered, the Registry resolves the unique product identifier, which must be a resolvable URL. It then retrieves the passport content from where it is hosted and validates it under Commission Implementing Regulation (EU) 2026/1778. The payload itself is never stored. Validation happens at the source.

This has practical consequences. If the passport address is unreachable, slow or misconfigured, registration fails. Operators keep control of their data, and they also keep responsibility for its availability.

Registration: verified organisations, atomic batches, idempotency

Registration starts with the organisation. Before submitting any product, an organisation must be verified. Verification includes a declaration sealed with a qualified electronic seal (QSeal) issued by a qualified trust service provider.

Submissions are asynchronous. A client sends a POST request to the submission endpoint with a batch of 1 to 100 items and receives a task that it can follow until processing completes. The batch rules are strict:

  • each submission covers one product group and one subgroup;
  • submissions are atomic, so a single non-compliant item means nothing in the batch is registered;
  • an Idempotency-Key header is mandatory, and resubmitting the same key returns the original task instead of creating a duplicate;
  • each registered item receives its uniqueRegistryIdentifier.

Atomicity and idempotency push quality control upstream. Data must be validated before submission. Retry logic must be built around the key so that network failures never produce double registrations. The production API base is reg.product-passport.ec.europa.eu.

One data language: SKOS, SHACL and the four access views

The Semantic Data Guide defines a single model. Master data is expressed in SKOS vocabularies and SHACL shapes. XML schemas, JSON schemas and JSON-LD contexts are generated from the shapes. The shapes are the reference, and every other format derives from them.

Registration is in JSON under standard EN 18216, aligned with EN 18223 from CEN and CENELEC JTC 24. The Commission declares one deviation: multilingual values are carried with xml:lang instead of the nested MultiLanguageValue structure. Implementations that followed the standard literally on this point will need adjusting.

The model is hierarchical. A core layer is common to all passports, followed by the product group and then the subgroup. Access rights are declared for each data concept, and the artifacts define four access views:

  • pub: the public view;
  • res1, res2 and res3: three restricted levels, each covering the data concepts assigned to it.

In practice, the same passport must be served differently depending on who asks. That requirement lands on whoever hosts the data.

Machine access and the duties of whoever hosts the data

Automated systems connect through service accounts. These use OAuth 2.0 Client Credentials with private_key_jwt, so there are no shared secrets. The organisation generates elliptic curve keys, registers the public key and signs its own assertions. Tokens live at most 15 minutes. Each organisation can hold up to 5 service accounts, with 2 active credentials each, which allows key rotation without downtime.

The Self-Hosted Authentication Guide applies to whoever hosts passport data. That includes operators hosting their own passports and service providers hosting on behalf of operators. The host must expose an OAuth 2.0 resource server at the passport address, with defined behaviour:

  • anonymous access sees only the public view;
  • the Registry calls with its own signed tokens (at+jwt, ES384, lifetime at most 120 seconds, scope dpp:registry:read);
  • an invalid token receives a flat 401, with no fallback;
  • a minimum conformance matrix of 13 tests applies.

Hosting a passport therefore means operating an authorisation-aware endpoint that the Registry can test. A static web page listing product data will not meet these requirements.

Built on these specifications

Ledger Consortium infrastructure implements these integration surfaces:

  • passport data produced in the Registry semantic model and registered through the API flows, with idempotent, atomic submissions;
  • machine-to-machine access through service accounts;
  • passports hosted and resolved with the four access levels and the Registry authentication model;
  • each passport record anchored on a governed blockchain, with certain date and integrity, no token and no crypto exposure, aligned with GDPR and eIDAS.

Ledger works with Confindustria and with eight chambers of commerce: JIACC (signed), Hungary, Serbia, ITKAM Germany, Egypt, France, Hong Kong and Los Angeles. It also works with Il Sole 24 Ore through Valore24 and with two European ministries, the Italian Ministry of Enterprises and Made in Italy and the Czech Ministry of Industry and Trade.

A working demo is available at /demo/. For how the Registry connects to customs controls, read the companion piece at /news/eu-dpp-registry-customs/. For the first product group in detail, see the battery passport article at /news/battery-passport-2027/. More updates are at /news/.

Operators can act now. The first step is to organise product data to the semantic model: core, product group and subgroup, with access rights mapped to the four views. The second is to choose hosting that already speaks the Registry language, from verified registration to authenticated resolution.