Kurz gesagt: Am 30. Oktober 2026 hat die Europäische Kommission die technische Dokumentation zur API des EU-DPP-Registers veröffentlicht. Sie erklärt, wie Software Pässe automatisch registriert. Ein Service Account ist ein technisches Konto für Software statt für eine Person. Er meldet jeden Aufruf für einen verifizierten Wirtschaftsakteur an, also das Unternehmen, das für das Produkt verantwortlich ist. Eine Einreichung kann bis zu 100 Pässe enthalten. Den Pass selbst ruft das Register danach über die Webadresse in seiner Produktkennung ab. Das bisher veröffentlichte produktspezifische Registrierungsschema deckt nur Batterien ab. Schon elf Tage vorher, am 19. Oktober, ist außerdem der Batterie-Leitfaden V3.2 der Kommission erschienen. Er ordnet 71 nummerierte Batterie-Datenpunkte für Februar 2027 ein. Dieser Leitfaden schafft keine Rechtspflichten und gibt nicht die offizielle Position der Kommission wieder. Die Pflicht selbst steht in Artikel 77 Absatz 1 der Batterieverordnung: Ab 18. Februar 2027 brauchen Batterien für Elektrofahrzeuge, Batterien für leichte Verkehrsmittel (LMT) und Industriebatterien über 2 kWh einen Batteriepass, wenn sie in Verkehr gebracht oder in Betrieb genommen werden.

Was hat die Kommission im Oktober 2026 veröffentlicht?

Alle Dokumente stehen auf der DPP-Ressourcenseite der Kommission. Das Register ist am 20. Juli 2026 mit einer Testumgebung gestartet; was das bedeutet hat, steht in unserem Beitrag zum Start des Registers. Die Durchführungsverordnung (EU) 2026/1778 legt die rechtlichen Regeln für das Register fest. Die Oktober-Dokumente erklären, wie deine Systeme sich anbinden. Sie ergänzen das bestehende Benutzerhandbuch für die Website des Registers.

[HTML-EMBED: Übersichtstabelle, siehe Block 2]

Laut Kommission werden die in den Leitfäden beschriebenen Testfunktionen schrittweise verfügbar, bevor das Register vollständig in Betrieb geht. Dass eine Schnittstelle beschrieben ist, heißt also noch nicht, dass jede Funktion schon läuft. Die Oktober-Leitfäden tragen Version 1.0, die OpenAPI-Dateien und die semantischen Dateien Version 1.0.0. Es sind also jeweils die ersten Fassungen, und mit Änderungen ist zu rechnen. Prüfe deshalb vor der Umsetzung, ob es schon neuere gibt. Der DPP Registry User Guide for Economic Operators beschreibt die Website. Die Fassung auf der Ressourcenseite ist v1.03 vom 16. September 2026. Sie ist also älter als die Oktober-Leitfäden und kann diese noch nicht berücksichtigen. Das ist wichtig, weil das Handbuch einen deutlichen Hinweis enthält: Zu diesem Zeitpunkt war es noch nicht möglich, einen Batteriepass erfolgreich zu registrieren, weil der semantische Katalog für Batterien gefehlt hat. Diesen Katalog beschreiben die Oktober-Dateien jetzt. Ob die Registrierung damit von Anfang bis Ende funktioniert, solltest du aber selbst testen, bevor du dich darauf verlässt.

Wie verarbeitet die DPP-Register-API Registrierungen?

Eine Einreichung, bis zu 100 Pässe

Laut API Integration Guide reichst du je API-Aufruf die Registrierungsdaten für 1 bis 100 Pässe ein. Alle Einträge einer Einreichung müssen zur selben Produktgruppe gehören und, wo es eine gibt, zur selben Untergruppe, zum Beispiel Batterien für Elektrofahrzeuge.

Nimmt das Register die Anfrage an, antwortet es mit HTTP 202 und einer Task-ID. Damit ist die Anfrage erst einmal nur zur Verarbeitung angenommen. Ob die Verarbeitung schon begonnen hat oder die Pässe registriert sind, sagt die Antwort allerdings nicht. Mit der Task-ID verfolgst du die Verarbeitung im Activity Dashboard, der Übersicht des Registers über deine Einreichungen. Die Ergebnisse je Pass kannst du als JSON oder CSV abrufen.

Das Register behandelt jede Einreichung nach dem Prinzip alles oder nichts (der Leitfaden nennt das atomar). Besteht ein einziger Pass die Prüfung nicht, wird keiner der Pässe aus dieser Einreichung registriert. Der Status COMPLETED heißt nur, dass die Verarbeitung abgeschlossen ist. Das Ergebnis kann trotzdem FAILED lauten. Prüfe deshalb das Ergebnis und finde über die Rückmeldungen je Pass die Ursache.

Sende bei jeder Einreichung einen Idempotency-Key mit. Das ist ein eindeutiger Schlüssel, den du selbst vergibst, und er verhindert, dass eine wiederholte Anfrage doppelt zählt. Schickst du dieselbe Einreichung unverändert noch einmal, etwa nach einer Zeitüberschreitung, verwendest du denselben Schlüssel. Änderst du die Einreichung, brauchst du einen neuen.

Für kleine Mengen beschreibt das Benutzerhandbuch zwei Wege über die Website: ein Online-Formular für einen einzelnen Pass oder das Hochladen einer JSON- oder XML-Datei. Du meldest dich mit EU Login an. Die einzelnen Schritte stehen in unserem Beitrag DPP im EU-Register registrieren.

Das Register liest deinen Pass unter seiner URL

Du lädst nicht den Pass hoch, sondern nur die Registrierungsdaten. Den Pass ruft das Register danach selbst ab, und zwar über die eindeutige Produktkennung, die eine HTTPS-Webadresse sein muss. Erreicht es den Pass bei der Prüfung nicht, scheitert die Registrierung. Laut Semantic Data Guide der Kommission fragt das Register den Pass als JSON ab, dem Pflichtformat nach EN 18216:2026. Dein gehosteter Pass muss deshalb als JSON verfügbar sein, egal was er sonst noch anbietet. Gespeichert wird im Register übrigens nur ein Registrierungseintrag, nicht der Pass selbst. Kennung und Hosting müssen also schon stehen, bevor du registrierst. Wie die Normen zusammenspielen, steht in den sechs harmonisierten DPP-Normen.

Welche Produktgruppen deckt die API bisher ab?

Nur Batterien. Die OpenAPI-Spezifikation beschreibt die API-Aufrufe in maschinenlesbarer Form. Version 1.0.0 enthält nur eine Einreichungsart: die Registrierung von Batteriepässen. Die semantischen Dateien legen die Passdaten in drei Ebenen fest: ein allgemeiner DPP-Kern, eine Ebene für Batterien und darunter je eine Ebene für Elektrofahrzeug-, Industrie- und LMT-Batterien. Außer dem Kern enthalten sie nur Dateien für Batterien. Das Paket enthält unter anderem JSON-Schemas, die den Aufbau der Daten prüfen, SHACL-Shapes mit Prüfregeln für verknüpfte Daten und JSON-LD-Kontexte, die jedem JSON-Feld eine gemeinsame, festgelegte Bedeutung geben. Dazu kommen gemeinsame Begriffslisten und Beispieldokumente.

Jede Batterie wird einzeln registriert. Das heißt aber nicht, dass jede Angabe nur für eine Batterie gilt: Der Batterie-Leitfaden bezieht die Angaben grundsätzlich auf das Batteriemodell und kennzeichnet die Ausnahmen für einzelne Batterien.

Wie authentifizieren Service Accounts API-Aufrufe?

Der Service Account Technical Integration Guide beschreibt den Zugang für Software. Ein Service Account ist an eine verifizierte Organisation gebunden. Was er darf, ist auf diese Organisation und die dem Konto zugewiesenen Berechtigungen beschränkt.

Die Anmeldung läuft in drei Schritten. Erstens erstellt dein System eine JWT-Client-Assertion, einen signierten Identitätsnachweis, und signiert ihn mit dem privaten Schlüssel des Kontos. Der Leitfaden empfiehlt eine Gültigkeit von 60 bis 120 Sekunden, die absolute Obergrenze liegt bei fünf Minuten. Zweitens fordert dein System über OAuth 2.0 Client Credentials ein Zugriffstoken an. Das ist ein übliches Verfahren für den Zugriff von Software auf Software. Zur Anmeldung nutzt es die Methode private_key_jwt und schickt den signierten Nachweis mit. Das Zugriffstoken gilt höchstens 15 Minuten. Drittens sendet dein System das Token bei jedem API-Aufruf an das Register mit. Der private Schlüssel bleibt beim Wirtschaftsakteur.

Vorher muss die Organisation selbst verifiziert sein. Artikel 4 Absatz 2 der Durchführungsverordnung (EU) 2026/1778 unterscheidet danach, ob eine juristische Person in der Union niedergelassen sein muss. Ist das vorgeschrieben, weist sie Identität und Niederlassung mit einem qualifizierten elektronischen Siegel oder einer qualifizierten elektronischen Attributsbescheinigung nach. Das ist eine beglaubigte elektronische Bestätigung der Unternehmensangaben. Für juristische Personen ohne diese Vorgabe gelten andere Regeln. Wer auf der Website des Registers arbeitet, meldet sich mit EU Login an.

In der Praxis heißt das: Verantwortlich für die Registrierung ist der Wirtschaftsakteur, der die Batterie in Verkehr bringt oder in Betrieb nimmt. Soweit Unionsrecht es vorsieht, kann ein verifizierter Dritter die Registrierung in deinem Auftrag ausführen, verantwortlich bleibst aber du. Ein DPP-Anbieter kann den Pass für dich hosten. Eine Anbindung über den Service Account deiner Organisation musst du freigeben. Der Anbieter kann dann nur die Berechtigungen nutzen, die diesem Konto zugewiesen sind. Schließe die Verifizierung deiner Organisation ab, bevor du mit der API-Registrierung beginnst.

Wie greift das Register auf geschützte Passdaten zu?

Teile eines Batteriepasses sind nicht öffentlich. Der Self-Hosted Authentication Guide beschreibt, wie das Register sie trotzdem liest. Die öffentlichen Daten liefert dein Host an jeden aus, ganz ohne Anmeldung. Für die geschützten Daten legt das Register ein Zugriffstoken des Authentifizierungsdienstes der Kommission vor. Dein Host, oder ein Hosting-Anbieter, der für dich handelt, prüft dieses Token und seine eigenen Zugriffsregeln. Erst dann liefert er öffentliche und geschützte Daten zusammen aus.

Die Batterie-Schemas teilen den Pass in eine öffentliche und drei geschützte Sichten. Die Empfängerkreise überschneiden sich:

• RES1: Personen mit berechtigtem Interesse, notifizierte Stellen, Marktüberwachungsbehörden und Kommission
• RES2: notifizierte Stellen, Marktüberwachungsbehörden und Kommission
• RES3: Personen mit berechtigtem Interesse, für Angaben zur einzelnen Batterie

Wie diese Sichten zu den Zugriffsregeln der Verordnung passen, steht in Batteriepass: Zugriffsrechte.

Welche Batterie-Datenpunkte ordnet der Leitfaden V3.2 für Februar 2027 ein?

Der Leitfaden der Kommission „Digital Batteries Passport: data points by category“ (Version 3.2 vom 19. Oktober 2026) enthält 71 nummerierte Datenpunkte. Für jeden Datenpunkt gibt er die Einordnung für Februar 2027 an, getrennt nach Elektrofahrzeug-, LMT- und Industriebatterien. Ein Feld kann verpflichtend, optional oder nur in bestimmten Fällen relevant sein. Andere Felder ordnet er als noch nicht zu befüllen oder anzuzeigen ein. Der Leitfaden sagt selbst, dass er nicht die offizielle Position der Kommission wiedergibt und keine Pflichten schafft. Verbindlich ist die Batterieverordnung.

Welche Felder ordnet der Leitfaden für Februar 2027 als noch nicht zu befüllen oder anzuzeigen ein? Beispiele:

• CO2-Fußabdruck-Erklärung und -Label: Laut Leitfaden wartet ihr Format noch auf einen Durchführungsrechtsakt
• Angaben zur Sorgfaltspflicht in der Lieferkette: Der Leitfaden verweist auf die Sorgfaltspflichten, die ab 18. August 2027 gelten
• Rezyklatanteile für Kobalt, Lithium, Nickel und Blei
• druckbare Gebrauchsanleitung: Der Leitfaden verweist auf den laufenden Omnibus

Diese Beispiele geben die Einordnung des Leitfadens wieder. Ausnahmen vom geltenden Recht folgen daraus nicht; prüfe das Recht, bevor du ein Feld leer lässt. Soweit nicht anders angegeben, beziehen sich die Angaben auf das Batteriemodell, nicht auf die einzelne Batterie. Was insgesamt in den Pass gehört und wer einen braucht, steht in unserem Batteriepass-Leitfaden; die Anforderungen an den Datenträger erklärt unser Beitrag zur Batterie-QR-Code-Pflicht.

Was ist bis 18. Februar 2027 zu tun?

• Die Verifizierung deiner Organisation im Register abschließen, falls noch nicht geschehen.
• Deine Batteriedaten Modell für Modell gegen die Liste V3.2 abgleichen und markieren, was der Leitfaden für Februar als verpflichtend einordnet. Dabei die Felder vermerken, die für die einzelne Batterie gelten.
• Für jede Batterie, die nach Artikel 77 Absatz 1 einen Pass braucht, sicherstellen, dass ihre Produktkennung über HTTPS zu einem Pass führt, der als JSON verfügbar ist.
• Festlegen, wer die geschützten Sichten ausliefert und wie das Token des Registers geprüft wird.
• Sobald die Testfunktionen verfügbar sind, ein Testpaket einreichen. Dazu gehören ein Paket, das die Prüfung nicht besteht, eine unveränderte Wiederholung mit demselben Idempotency-Key und eine korrigierte Einreichung mit neuem Schlüssel.

Es bleiben also noch rund drei Monate. Die Termine für andere Produktgruppen stehen in unserer DPP-Timeline und je Produktgruppe auf der Compliance-Seite.

Wo dpp.cloud ansetzt

dpp.cloud erstellt Pässe aus deinen Produktdaten, etwa aus deinem PIM für Produktinformationen oder deinem ERP-System für Unternehmensprozesse. Dazu erzeugt es einen QR-Code nach GS1 Digital Link, der den Pass öffnet. Wie das funktioniert, steht in DPP erstellen aus PIM-Daten, in DPP-Integration mit SAP und in unserem Beitrag zu GS1 Digital Link. Die Registrierung im Register übernimmt dpp.cloud dagegen nicht, die bleibt bei dir als Wirtschaftsakteur. Wenn du die Leitfäden mit deinem eigenen Setup durchgehen willst, buche ein Strategiegespräch.

Quellen

• Europäische Kommission, Digital Product Passport: resources and documentation (API Integration Guide, OpenAPI Specifications, Semantic Data Guide und Artifacts, Service Account Technical Integration Guide, Self-Hosted Authentication Guide, alle vom 30. Oktober 2026; DPP Registry User Guide for Economic Operators v1.03 vom 16. September 2026; Batterie-Leitfaden V3.2 vom 19. Oktober 2026): single-market-economy.ec.europa.eu/single-market/digital-product-passport/resources-documentation_en
• Europäische Kommission, „The Digital Product Passport Registry is now live“ (20. Juli 2026): single-market-economy.ec.europa.eu/news/digital-product-passport-registry-now-live-2026-07-20_en
• Durchführungsverordnung (EU) 2026/1778 (DPP-Register), Artikel 4: data.europa.eu/eli/reg_impl/2026/1778/oj
• Verordnung (EU) 2023/1542 (Batterieverordnung), Artikel 48 und 77: eur-lex.europa.eu/eli/reg/2023/1542/oj