EN 18222: API för produktpassets livscykel och sökbarhet

EN 18222 är den europeiska standarden för det programmeringsgränssnitt (API) som ett system för digitala produktpass ska erbjuda. Den beskriver hur andra system hittar, läser och hanterar pass under hela produktens livscykel. Standarden berör den som driver passsystem, alltså tillverkare, varumärken och leverantörer av passtjänster, och den som bygger verktyg som läser pass i stor skala, till exempel marknadsplatser, återvinnare, reparatörer och myndigheter.

Syftet är enkelt att förklara: om alla passsystem har samma anrop med samma namn och samma vägar kan ett verktyg som är byggt mot ett system läsa från alla andra utan specialanpassning. EN 18222 är en av sex harmoniserade standarder som CEN godkände den 3 maj 2026, som fastställdes som svensk standard den 27 maj 2026 och vars referenser publicerades i EUT den 15 juli 2026. Den här artikeln går igenom vad standarden omfattar och vad den betyder för den som bygger eller köper ett passsystem. Se också översikten över DPP-standarderna.

Vad standarden omfattar

Den fullständiga beteckningen är EN 18222:2026 Digital Product Passport – Application Programming Interfaces (APIs) for the product passport lifecycle management and searchability. Den svenska utgåvan SS-EN 18222:2026 är på 20 sidor. Standarden har tagits fram av CEN-CLC/JTC 24 på uppdrag av kommissionens standardiseringsbegäran M/604 i ändrad lydelse (M/604 Amd 1).

Enligt omfattningsbeskrivningen som SIS publicerar ska standarden standardisera specifikationerna för produktpassets API så som ESPR kräver. API:et har två uppgifter: att göra pass sökbara och att ge de medel som behövs för att hantera ett pass under produktens livscykel.

På CEN och CENELEC:s webbinarium den 25 juni 2026 sammanfattades standarden i tre punkter: detaljerade och entydiga API-definitioner som är helt integrerade i JTC 24:s ramverk av standarder, alla relevanta livscykeloperationer enligt M/604, och en låg tröskel för att införa API:et i vilken programvarumiljö som helst. I webbinariets bild över vad en ekonomisk aktör gör kopplas EN 18222 till steget att registrera passet och länka till passdatan via den unika identifieraren och API:et.

Vad den kräver i praktiken

Standardtexten säljs via de nationella standardiseringsorganen och får inte återges. Detaljerna nedan kommer från den licensierade SS-EN-utgåvan så som vi läste den när vi byggde DPP Agents validator. Kontrollera dem mot ert eget exemplar.

Tre obligatoriska läsanrop

Klausul 4.1 delar in API-metoderna i sådana som ska finnas (shall) och sådana som bör finnas (should). Tre metoder ska finnas, både hos den som skapat passet eller dess tjänsteleverantör och hos backupleverantören, och alla tre läser data. Klausul 8.2 anger deras vägar:

Metod	Anrop	Vad den gör
ReadDPPById	GET v1/dpps/{dppId}	Läser ett pass utifrån passets eget id.
ReadDPPByProductId	GET v1/dppsByProductId/{productId}	Läser passet utifrån produktens identifierare.
ReadDPPIdsByProductIds	POST v1/dppsByProductIds	Slår upp passens id för en lista med produktidentifierare.

Läsande verktygPasssystem

ReadDPPByIdGET v1/dpps/{dppId}

JSON · passet

ReadDPPByProductIdGET v1/dppsByProductId/{productId}

JSON · passet

ReadDPPIdsByProductIdsPOST v1/dppsByProductIds

JSON · passens id för listan

Att läsanropen är de obligatoriska följer av vem som behöver dem. Den som tar emot en produkt, eller ska kontrollera ett helt sortiment, utgår från produktidentifierare och behöver komma fram till passen. Den tredje metoden, som tar en lista, är den som gör det möjligt att behandla en hel katalog i ett anrop i stället för ett i taget.

Standarden innehåller fler livscykeloperationer än de tre läsanropen, i linje med M/604. CreateDPP, DeleteDPPById och ReadDPPVersionByIdAndDate bör finnas hos tjänsteleverantören och backupleverantören, och ReadDataElement bör finnas hos alla som erbjuder passet. UpdateDPPById ska finnas om behöriga tredje parter har rätt att uppdatera delar av passet, och varje ändring ska då arkiveras enligt EN 18221 (klausul 4.1 och 4.7). Läs standardtexten innan ni bestämmer er.

Fel och åtkomst

Ett anrop som misslyckas bör svara med ett resultatobjekt med felmeddelanden i det format standarden anger (klausul 7.2), inte med en vanlig webbsida. Metodbeskrivningarna i klausul 4 hänvisar reglerna för åtkomst till EN 18246. Ett anrop kan alltså kräva behörighet när det gäller skyddad data. Offentlig passdata ska däremot enligt EN 18246 (avsnitt 4.3) serveras utan autentisering.

Ingen standardiserad upptäckt

EN 18222 anger vägarna relativt API:ets bas. Basen ingår i passets registreringspost till EU:s register (dppApiEndpoint, klausul 7.1), men standarden anger ingen fast plats för den och inget sätt att hitta den utifrån passets adress. Ett verktyg som bara har koden på produkten kan alltså inte utan vidare räkna ut var en viss utgivares API ligger. I praktiken betyder det att den som driver ett passsystem bör dokumentera sin API-bas tydligt och gärna lägga den på en förutsägbar plats, till exempel /api/v1/ på samma värd som passen.

En kontrollista för den som köper ett passsystem

1. Finns de tre läsanropen med exakt de namn och vägar som standarden anger?
2. Svarar de med JSON, både vid träff och vid fel?
3. Kan offentlig data läsas utan inloggning, medan skyddad data kräver behörighet?
4. Är API-basen dokumenterad?
5. Går anropen över HTTPS och HTTP/2 enligt EN 18216?

Hur EN 18222 hänger ihop med de andra standarderna och lagen

ESPR artikel 10.1 d kräver att passdata ska vara maskinläsbara, strukturerade, sökbara och överförbara utan leverantörsinlåsning. Artikel 11 b ger kunder, tillverkare, importörer, återförsäljare, reparatörer, återvinnare, myndigheter och andra aktörer rätt till kostnadsfri och enkel åtkomst efter sina åtkomsträttigheter, och artikel 11 f begränsar rätten att lägga in och ändra data på samma sätt. Ett standardiserat API är det tekniska svaret på de kraven. Genomförandebeslut (EU) 2026/1736 konstaterar att EN 18222 tillsammans med de fem andra uppfyller kraven i artiklarna 10 och 11, och enligt artikel 41.2 ger det en presumtion om överensstämmelse i den utsträckning standarden täcker kraven.

API:et är inte detsamma som EU:s register. Enligt ESPR artikel 13 skulle kommissionen senast den 19 juli 2026 inrätta ett register som lagrar åtminstone de unika identifierarna, och den ekonomiska aktören laddar upp dem. Registret svarar med ett unikt registreringsid. EN 18222 anger anropet för det, RegisterProductDPP (POST v1/registerDPP, klausul 5.2 och 8.3), som registret tillhandahåller. Genomförandeförordning (EU) 2026/1778 av den 16 juli 2026 fastställer hur registret ska genomföras. Själva passet lagras av den ekonomiska aktören eller av en leverantör av passtjänster (artikel 11 c). Registret pekar alltså ut passen, medan API:et enligt EN 18222 är där passen faktiskt läses.

Inom serien vilar EN 18222 på de andra standarderna:

• EN 18216 anger protokoll och format som anropen går över.
• EN 18219 anger de produktidentifierare som skickas in som parametrar.
• EN 18223 anger strukturen på passet som anropen returnerar.
• EN 18221 anger hur versioner arkiveras och hur passet överlever via en backup.
• EN 18239 och EN 18246 anger åtkomsträttigheter och dataautentisering. De fastställdes den 16 september 2026 men är inte citerade i EUT och ger ingen presumtion om överensstämmelse.

För batterier kräver batteriförordningen i artikel 77.5 att informationen ska vara maskinläsbar, strukturerad och sökbar, och artikel 78 b att konsumenter, ekonomiska aktörer och andra får kostnadsfri åtkomst enligt sina rättigheter i bilaga XIII och den genomförandeakt som artikel 77.9 föreskriver. Beslut 2026/1736 publicerar dock referenserna till stöd för ESPR, inte för batteriförordningen.

Vanliga missförstånd

"Vi har redan ett REST-API, så vi uppfyller EN 18222"

Ett eget API, hur bra det än är, uppfyller inte syftet om metodernas namn och vägar skiljer sig från standardens. Hela poängen är att ett verktyg ska fungera mot alla system utan att skrivas om.

"Registret lagrar passen"

Nej. Enligt ESPR artikel 13 lagrar registret åtminstone de unika identifierarna, och därutöver varukoden för produkter som ska övergå till fri omsättning samt den data som de delegerade akterna anger. Passet ligger hos den ekonomiska aktören eller hos en leverantör av passtjänster.

"Ett API betyder att all data blir offentlig"

Nej. Åtkomsten styrs av de rättigheter som anges i de delegerade akterna, och standarden hänvisar åtkomstreglerna till EN 18246. Offentlig data ska vara öppen. Skyddad data får kräva behörighet.

"Om API:et inte svarar på /api/v1/ saknas det"

Det går inte att dra den slutsatsen, eftersom EN 18222 inte anger var basen ska ligga. Det enda man vet är att API:et inte ligger där man letade.

Så ser det ut i praktiken

DPP Agent, som Blippa utvecklar, erbjuder de tre läsanropen under /api/v1/: dpps/{dppId}, dppsByProductId/{productId} och dppsByProductIds. Validatorn på dppagent.com provar samma anrop mot vilken passutgivare som helst, på /api/v1/ och /v1/. Hittar den inget redovisas resultatet som delvis, inte som underkänt, eftersom standarden inte anger var API:et ska ligga.