DPP-Registry: Was die neuen technischen EU-Unterlagen vom 30. Oktober 2026 für Hersteller und Softwareanbieter bedeuten

Das Wichtigste

Die EU-Kommission hat am 30. Oktober 2026 ein zusammengehöriges technisches Dokumentenpaket für die Anbindung an die DPP-Registry veröffentlicht: API-Integrationsleitfaden, OpenAPI-Spezifikationen, Semantikleitfaden samt Datenartefakten sowie Anleitungen für Service-Accounts und selbst gehostete Produktpässe. Der API-Leitfaden beschreibt asynchrone Registrierungen mit 202-Antwort, Task-Verfolgung und bis zu 100 Pässen je atomarer Einreichung. Die Semantikunterlagen konkretisieren SKOS-Taxonomien, SHACL-Prüfregeln, JSON Schema, JSON-LD und XML/XSD. Für Hersteller und Softwareanbieter werden damit technische Implementierungsanforderungen erheblich konkreter. Die Veröffentlichung von Leitfäden ist jedoch kein Nachweis, dass alle produktiven Schnittstellen freigeschaltet sind, und begründet für sich keine neue gesetzliche Pflicht.

1. Amtliche Veröffentlichung und Umfang

Die Generaldirektion Binnenmarkt (DG GROW) führt seit 30. Oktober 2026 auf der amtlichen DPP-Ressourcenseite sechs zusammengehörige technische Ressourcen: (1) API Integration Guide (PDF v1.0), (2) OpenAPI Specifications (ZIP), (3) Semantic Data Guide (PDF v1.0), (4) Semantic Data Artifacts (ZIP), (5) Service Account Technical Integration Guide (PDF v1.0) und (6) Self-Hosted Authentication Guide (PDF v1.0). Die vier PDF-Titelseiten nennen ausdrücklich den 30.10.2026 und Version 1.0. Beide ZIP-Pakete sind amtlich als Downloads gelistet; ihr Dateiinhalt konnte in diesem Lauf technisch nicht entpackt werden. Die zuvor veröffentlichte allgemeine Registry-Bedienungsanleitung V3 vom September ist hiervon zu unterscheiden.

2. Registry-API: Registrierung und Rückmeldung

Der API-Leitfaden beschreibt POST /api/v1/dpp/submission für ein bis 100 DPP-Elemente gleicher Produktgruppe. Jeder Eintrag enthält einen uniqueProductIdentifier (UPI) als erreichbare URL; produktgruppenspezifische Zusatzfelder können nötig sein. Die Annahme mit HTTP 202 Accepted erzeugt eine asynchrone Aufgabe (taskId), ist aber noch keine erfolgreiche Registrierung. Über GET /api/v1/tasks/{taskId} und /items werden Bearbeitungsstatus, fachliches Ergebnis und einzelne Validierungsfehler abgefragt. Ein abgeschlossener Task kann fachlich FAILED sein. Die Einreichung ist atomar: Scheitert ein Element, wird kein Element des Batches registriert. Für Wiederholungen ist ein Idempotency-Key vorgeschrieben; die Dokumentation nennt getrennte Regeln für fachliche und technische Fehler.

3. Semantisches Datenmodell und Formate

Der Semantikleitfaden legt eine Hierarchie aus Kernvokabular, Produktgruppen und gegebenenfalls Untergruppen fest. SKOS definiert kontrollierte Begriffe; SHACL-Shapes enthalten Struktur-, Kardinalitäts- und Wertregeln. Daraus werden JSON Schemas, XSDs und JSON-LD-Kontexte abgeleitet. Die Dokumentation beschreibt JSON, XML und JSON-LD/RDF als Austausch- und Validierungsrepräsentationen, wobei JSON nach dem zitierten EN 18216:2026 das verpflichtende Registrierungsformat ist. Die produktspezifischen Regeln, beispielsweise für EV-, Industrie- oder LMT-Batterien, müssen aus den veröffentlichten Artefakten und jeweils einschlägigen Rechtsakten konkretisiert werden; die ZIP-Validierungsdateien sind vor einer produktiven Implementierung vollständig auszuwerten.

4. Maschinenanbindung über Service-Accounts

Der Service-Account-Leitfaden sieht eine zuvor verifizierte Organisation und einen angelegten technischen Account vor. Die Authentifizierung erfolgt über OAuth 2.0 Client Credentials mit signiertem private_key_jwt und kurzlebigen Bearer-Tokens; gemeinsam genutzte Client-Secrets sind laut Leitfaden nicht vorgesehen. Der private Schlüssel bleibt ausschließlich beim Unternehmen. Beschrieben werden Schlüsselrotation, Berechtigungen, Test- und Produktivumgebungen, Token-Abruf sowie technische Fehlerszenarien. Die Dokumentation nennt maximal fünf operative Service-Accounts pro Organisation und höchstens zwei gleichzeitig aktive Schlüssel je Account.

5. Selbst gehostete Produktpässe und Zugriffsschutz

Die EU beschreibt ein dezentrales Modell: Der DPP kann auf einem HTTPS-Server des Wirtschaftsteilnehmers liegen, während die Registry über die UPI-URL darauf zugreift und den Pass validiert. Ohne Authorization-Header darf nur die öffentliche Darstellung zurückgegeben werden. Für geschützte Informationen prüft der eigene Server lokal die Signatur eines von der DPP-Authentifizierungsstelle ausgestellten JWT, die erwartete Audience und den berechtigten requestor-Identifier; bei ungültigem Token sind 401 und bei fehlender Berechtigung 403 vorgesehen. Das geschützte Material darf nicht durch einen Rückfall auf anonymen Zugriff offengelegt werden. Das Modell bestätigt die technische Bedeutung dauerhafter Produkt-URLs, Serververfügbarkeit und eines getrennten Berechtigungssystems.

6. Rechtliche Einordnung

Rechtsrahmen sind insbesondere die Ökodesign-Verordnung (EU) 2024/1781 und die jeweils produktspezifischen Vorgaben. Die Leitfäden sind technische Umsetzungsdokumente, keine neue Verordnung und kein allgemeiner sofortiger DPP-Pflichtbeginn für sämtliche Waren. Der API-Leitfaden verweist auf die Durchführungsverordnung (EU) 2026/1778 als Validierungsbezug; Reichweite und Rechtswirkung sind anhand des amtlichen Normtexts getrennt zu prüfen. Aus der Dokumentveröffentlichung allein folgt nicht, dass die produktive Registry für jede Produktgruppe schon verfügbar oder verpflichtend ist.

7. Konkrete Unternehmensmaßnahmen

Hersteller und DPP-Softwareanbieter sollten Produktgruppe und Pass-Granularität bestimmen, dauerhaft auflösbare UPI-URLs und öffentlich/geschützt getrennte Inhalte planen, technische Schemas und SHACL-Regeln versionssicher integrieren, Registrierungsjobs mit Task-/Fehlerbehandlung und Idempotenz umsetzen, Service-Account-Schlüssel sicher verwalten und eine Teststrecke für Batchfehler aufbauen. Für den produktiven Einsatz sind die beiden ZIP-Pakete einschließlich konkreter OpenAPI-Dateien und Validierungsartefakte zu prüfen, die aktuell bereitgestellten Endpunkte zu verifizieren und die jeweiligen sektorspezifischen Rechtsanforderungen gesondert zu bestimmen.

Amtliche Primärquellen

Fachliche Einordnung mit amtlichen EU-Quellen. Technische Leitfäden begründen nicht für sich neue Pflichten; geplante Kriterien sind nicht verbindlich. Redaktioneller Stand 02.11.2026.