EN 18222: APIs for product passport lifecycle management and searchability

EN 18222 is the European standard for the application programming interface (API) that a digital product passport system has to offer. It describes how other systems find, read and manage passports throughout a product's life cycle. It concerns those who run passport systems, meaning manufacturers, brands and passport service providers, and those who build tools that read passports at scale, such as marketplaces, recyclers, repairers and authorities.

The purpose is easy to state: if every passport system offers the same calls with the same names and paths, a tool built against one system can read from all the others without custom work. EN 18222 is one of six harmonised standards approved by CEN on 3 May 2026, adopted as Swedish standards on 27 May 2026, whose references appeared in the Official Journal on 15 July 2026. This article covers what the standard contains and what it means for anyone building or buying a passport system. See also the overview of the DPP standards.

What the standard covers

The full reference is EN 18222:2026 Digital Product Passport – Application Programming Interfaces (APIs) for the product passport lifecycle management and searchability. The Swedish edition, SS-EN 18222:2026, runs to 20 pages. It was drafted by CEN-CLC/JTC 24 in response to the Commission's standardisation request M/604 as amended (M/604 Amd 1).

According to the scope statement published by SIS, the standard sets out the specifications for the passport API as mandated by ESPR. The API has two jobs: to make passports searchable, and to provide the means needed to manage a passport over the product's life cycle.

At the CEN and CENELEC webinar on 25 June 2026 the standard was summed up in three points: detailed and unambiguous API definitions fully integrated into the JTC 24 framework of standards, all relevant life cycle operations according to M/604, and a low threshold for implementation in any software environment. On the webinar's map of what an economic operator does, EN 18222 belongs to the step of registering the passport and linking to its data via the unique identifier and the API.

What it requires in practice

The text is sold through the national standards bodies and cannot be reproduced. The details below come from the licensed SS-EN edition as we read it when building DPP Agent's validator. Check them against your own copy.

Three mandatory read methods

Clause 4.1 divides the API methods into those that shall be provided and those that should be. Three are mandatory, both at the passport's creator or its service provider and at the back-up service provider, and all three read data. Clause 8.2 gives their paths:

Method	Call	What it does
ReadDPPById	GET v1/dpps/{dppId}	Reads a passport by the passport's own id.
ReadDPPByProductId	GET v1/dppsByProductId/{productId}	Reads the passport by the product's identifier.
ReadDPPIdsByProductIds	POST v1/dppsByProductIds	Looks up the passport ids for a list of product identifiers.

Reading toolPassport system

ReadDPPByIdGET v1/dpps/{dppId}

JSON · the passport

ReadDPPByProductIdGET v1/dppsByProductId/{productId}

JSON · the passport

ReadDPPIdsByProductIdsPOST v1/dppsByProductIds

JSON · passport ids for the list

That the read methods are the mandatory ones follows from who needs them. Someone receiving a product, or checking a whole range, starts from product identifiers and has to get to the passports. The third method, which takes a list, is what makes it possible to process a whole catalogue in one request rather than one product at a time.

The standard contains more life cycle operations than the three reads, in line with M/604. CreateDPP, DeleteDPPById and ReadDPPVersionByIdAndDate should be offered by the service provider and the back-up provider, and ReadDataElement by everyone who offers the passport. UpdateDPPById is mandatory if authorised third parties have the right to update parts of the passport, and every change must then be archived under EN 18221 (clauses 4.1 and 4.7). Read the text before deciding.

Errors and access

A failed call should answer with a result object carrying error messages in the format the standard defines (clause 7.2), not with an ordinary web page. The method descriptions in clause 4 refer the rules on access to EN 18246. A call may therefore require authorisation where restricted data is concerned. Public passport data, on the other hand, is to be served without authentication under EN 18246 (clause 4.3).

No standard discovery

EN 18222 gives the paths relative to the API's base. The base is part of the passport's registry entry (dppApiEndpoint, clause 7.1), but the standard sets no fixed location for it and no way to find it from the passport's address. A tool that only has the code on the product cannot simply work out where a given publisher's API lives. In practice, anyone running a passport system should document the API base clearly and preferably put it somewhere predictable, such as /api/v1/ on the same host as the passports.

A checklist for buyers of a passport system

1. Are the three read methods present, with exactly the names and paths the standard gives?
2. Do they answer in JSON, on success and on error?
3. Can public data be read without logging in, while restricted data requires authorisation?
4. Is the API base documented?
5. Do the calls run over HTTPS and HTTP/2 as EN 18216 requires?

How EN 18222 relates to the other standards and the law

ESPR Article 10(1)(d) requires passport data to be machine-readable, structured, searchable and transferable without vendor lock-in. Article 11(b) gives customers, manufacturers, importers, dealers, repairers, recyclers, authorities and other actors free and easy access according to their access rights, and Article 11(f) restricts the right to introduce or change data in the same way. A standard API is the technical answer to those requirements. Implementing Decision (EU) 2026/1736 states that EN 18222, together with the other five, satisfies Articles 10 and 11, and under Article 41(2) that gives a presumption of conformity to the extent the standard covers them.

The API is not the same thing as the EU registry. Under ESPR Article 13, the Commission was to set up a registry by 19 July 2026 that stores at least the unique identifiers, which the economic operator uploads. The registry answers with a unique registration identifier. EN 18222 defines the call for that, RegisterProductDPP (POST v1/registerDPP, clauses 5.2 and 8.3), which the registry provides. Implementing Regulation (EU) 2026/1778 of 16 July 2026 lays down the arrangements for the registry. The passport itself is stored by the economic operator or by a passport service provider (Article 11(c)). The registry points to passports; the EN 18222 API is where passports are actually read.

Within the series, EN 18222 rests on the other standards:

• EN 18216 sets the protocols and formats the calls run over.
• EN 18219 sets the product identifiers passed in as parameters.
• EN 18223 sets the structure of the passport the calls return.
• EN 18221 sets how versions are archived and how the passport survives through a back-up.
• EN 18239 and EN 18246 set access rights and data authentication. They were approved on 16 September 2026 but are not cited in the Official Journal and give no presumption of conformity.

For batteries, the Batteries Regulation requires in Article 77(5) that the information be machine-readable, structured and searchable, and in Article 78(b) that consumers, economic operators and others have free access according to their rights under Annex XIII and the implementing act provided for in Article 77(9). Decision 2026/1736, however, publishes the references in support of ESPR, not of the Batteries Regulation.

Common misunderstandings

"We already have a REST API, so we meet EN 18222"

Your own API, however good, does not serve the purpose if its method names and paths differ from the standard's. The whole point is that one tool works against every system without being rewritten.

"The registry stores the passports"

No. Under ESPR Article 13 the registry stores at least the unique identifiers, plus the commodity code for products to be released for free circulation and any data the delegated acts specify. The passport stays with the economic operator or a passport service provider.

"An API means all data becomes public"

No. Access follows the rights set in the delegated acts, and the standard refers the access rules to EN 18246. Public data must be open; restricted data may require authorisation.

"If the API does not answer at /api/v1/, it does not exist"

That conclusion cannot be drawn, because EN 18222 does not say where the base has to be. All you know is that the API is not where you looked.

How this looks in practice

DPP Agent, developed by Blippa, offers the three read methods under /api/v1/: dpps/{dppId}, dppsByProductId/{productId} and dppsByProductIds. The validator at dppagent.com tries the same calls against any passport publisher, at /api/v1/ and /v1/. If it finds nothing, it reports a partial result rather than a failure, since the standard does not say where the API has to be.