DPP-Register-API: Batteriepässe Schritt für Schritt bei der EU registrieren

TL;DR

• Am 30. Oktober 2026 hat die Europäische Kommission die technischen Spezifikationen für die DPP-Register-API veröffentlicht: einen Integrationsleitfaden, OpenAPI-Dateien, Leitfäden zur Authentifizierung über Dienstkonten und zur Authentifizierung bei Selbst-Hosting sowie die semantischen Datenmodelle für Batterien.
• Die Registrierung ist asynchron und folgt dem Alles-oder-nichts-Prinzip: Sie senden bis zu 100 Pässe pro Übermittlung, das Register ruft jeden Pass unter seiner Webadresse ab und validiert ihn, und wenn ein Element fehlschlägt, wird keines registriert.
• Batterien sind bisher die einzige definierte Produktgruppe. EV-, LMT- und Industriebatterien über 2 kWh benötigen ab dem 18. Februar 2027 einen registrierten Pass, und Ihre Organisation muss mit einem qualifizierten elektronischen Siegel verifiziert sein, bevor irgendein API-Aufruf funktioniert.

Über die DPP-Register-API registrieren ein Hersteller, ein Einführer oder die für sie tätige Plattform digitale Produktpässe bei der EU, ohne sich Produkt für Produkt durch ein Webformular zu klicken. Das Register selbst ist seit dem 20. Juli 2026 in Betrieb. Was am 30. Oktober hinzukam, sind die Details, die ein Entwickler braucht, um eine Anbindung zu bauen: Endpunkte, Authentifizierung, Fehlercodes, Polling-Regeln und die Datenmodelle, gegen die das Register Pässe validiert.

Dieser Leitfaden richtet sich an die Person, die dafür sorgen muss, dass Batteriepässe bis Februar im Register erscheinen. Er folgt den Dokumenten in der Reihenfolge, in der Sie ihnen begegnen werden, und trennt, was entschieden ist, von dem, was noch offen ist. Was das Register ist und warum es existiert, erklärt unser Leitfaden zum EU-DPP-Register. Alle folgenden Angaben gelten mit Stand November 2026.

Was hat die Kommission am 30. Oktober veröffentlicht?

Sechs technische Dokumente sind auf der DPP-Ressourcenseite der Kommission erschienen, ohne eine Meldung, die sie ankündigte. Sie stehen neben dem User Guide for Economic Operators vom September 2026.

Am 19. Oktober hat die Kommission außerdem Version 3.2 ihres Leitfadens zum Batteriepass veröffentlicht, der die Datenpunkte nach Batteriekategorie auflistet. Wir behandeln ihn weiter unten.

Der verbindliche Teil ist die Durchführungsverordnung (EU) 2026/1778 vom 16. Juli 2026. Artikel 3 Buchstabe b sieht eine API für die Registrierung vor, Artikel 8 Absatz 6 erlaubt die Registrierung über die Benutzeroberfläche oder die API, und Artikel 8 Absatz 7 verlangt automatische Prüfungen von Semantik und Granularität. Mit den Spezifikationen setzt die Kommission diese Artikel um.

Was macht das Register mit Ihrem Pass?

Das Register ist ein Index, kein Speicher. Sie senden ihm für jeden Pass eine eindeutige Produktkennung (UPI), und die API verlangt, dass diese UPI eine HTTPS-URL ist. Bei der Übermittlung ruft das Register diese URL auf, holt den Pass ab und validiert ihn gegen das Datenmodell der Produktgruppe. In den Worten des Integrationsleitfadens: Das Register „does not persist the fetched DPP payload content", es speichert den abgerufenen Inhalt also nicht.

Diese eine Designentscheidung bestimmt den größten Teil der technischen Arbeit. Der Pass muss im Moment der Übermittlung online, vollständig und gültig sein, nicht später. Wenn das Register ihn nicht erreichen kann, schlägt das Element mit UPI_NOT_RESOLVABLE fehl. Wenn der Inhalt nicht dem Schema entspricht, schlägt es als ITEM_NON_COMPLIANT fehl. Ein Ablauf, der zuerst registriert und den Pass erst danach veröffentlicht, funktioniert nicht.

Nach erfolgreicher Registrierung erhalten Sie nach Artikel 9 der Durchführungsverordnung einen Registrierungsnachweis, versehen mit dem qualifizierten elektronischen Siegel der Kommission und 90 Tage lang abrufbar. Laden Sie ihn herunter und archivieren Sie ihn; er ist Ihr Beleg dafür, dass und wann der Pass registriert wurde.

Was muss vor dem ersten API-Aufruf vorhanden sein?

Mehr, als die meisten Teams erwarten, und fast nichts davon ist Code.

Eine verifizierte Organisation. Nutzer melden sich mit EU Login an, aber die API lehnt Anfragen einer nicht verifizierten Organisation mit einem 403 ab. Nach Artikel 4 der Durchführungsverordnung weist eine juristische Person ihre Identität und Niederlassung mit einem qualifizierten elektronischen Siegel (oder einer elektronischen Attributsbescheinigung) nach; ein Einzelunternehmer kann eine qualifizierte elektronische Signatur oder eine eID mit dem eIDAS-Vertrauensniveau „hoch" verwenden. In der Praxis stellt Ihnen das Register eine von der Kommission gesiegelte Erklärung bereit, die Sie signieren oder siegeln. Der verifizierte Status gilt, bis Ihre Identifizierungsmittel ablaufen, höchstens aber drei Jahre; danach müssen Sie sich erneut verifizieren.

Ein qualifiziertes Siegel erhalten Sie von einem qualifizierten Vertrauensdiensteanbieter, mit eigenen Identitätsprüfungen. Wenn Ihr Unternehmen keines besitzt, fangen Sie hier an.

Ein Administrator und ein Dienstkonto. Der Administrator Ihrer Organisation legt Dienstkonten (Service Accounts) in der Oberfläche des Registers an. Ein Dienstkonto ist eine nicht menschliche Identität, die an Ihre verifizierte Organisation gebunden ist, und es benötigt die Rolle, die das Registrieren von DPPs erlaubt. Die Organisation wird aus dem Zugriffstoken übernommen, Sie übergeben in der Anfrage also nie eine Organisations-ID.

Produktklassifizierung. Jede Übermittlung nennt eine Produktgruppe und eine Untergruppe, die Sie über GET /api/v1/dpp/product-groups abrufen, statt sie fest zu codieren. Heute liefert dieser Aufruf eine Gruppe, BATTERIES, mit den Untergruppen EV, LMT und Industrie.

Wie authentifiziert sich ein Dienstkonto?

Das Register verwendet OAuth 2.0 Client Credentials mit private_key_jwt. Der Leitfaden ist unmissverständlich: „Shared client secrets are not supported." Gemeinsam genutzte Client Secrets werden also nicht unterstützt. Ihr System hält einen privaten Schlüssel, signiert damit eine kurzlebige Assertion und tauscht sie gegen ein Zugriffstoken.

Die Details, über die viele stolpern werden:

• Nur Schlüssel auf Basis elliptischer Kurven (ES256, ES384 oder ES512). RSA-Schlüssel werden nicht akzeptiert. Sie laden den öffentlichen Schlüssel als JWK oder PEM hoch, und der Leitfaden empfiehlt, den privaten Schlüssel in einem Hardware-Sicherheitsmodul aufzubewahren.
• Kurze Assertions. Die Client Assertion sollte nach 60 bis 120 Sekunden ablaufen, nie nach mehr als 5 Minuten, mit jedes Mal einer neuen jti.
• Ein Ressourcenindikator. Die Token-Anfrage muss das Register als Ressource benennen, mit dem für jede Umgebung veröffentlichten Wert.
• Kurze Tokens. Zugriffstokens gelten höchstens 15 Minuten, Ihr Client muss sie also während langer Batch-Läufe erneuern.
• Grenzen. Bis zu 5 Dienstkonten pro Organisation und 2 aktive Anmeldedaten pro Konto, was eine Schlüsselrotation ohne Ausfallzeit möglich macht. Für Anmeldedaten wird eine Laufzeit von einem Jahr empfohlen, höchstens zwei.

Wenn eine Plattform Pässe für Sie registriert, ist das Modell, das die Dokumente der Version 1.0 beschreiben, ein Dienstkonto innerhalb Ihrer verifizierten Organisation. So funktioniert die Integration heute, aber es ist nicht der einzige Weg, den das Recht zulässt. Die Durchführungsverordnung sieht auch verifizierte Dritte vor, die im Namen eines Wirtschaftsakteurs handeln: Artikel 6 Absatz 1 erlaubt verifizierten Wirtschaftsakteuren, Zugriffsrechte an Dritte zu delegieren, sofern das Unionsrecht dies vorsieht, Artikel 8 Absatz 2 erlaubt einem verifizierten Dritten in diesem Fall, Registrierungshandlungen vorzunehmen, und Artikel 19 Absatz 4 verlangt, dass ein von einem Wirtschaftsakteur bevollmächtigter Dritter eine eigene Verifizierung durchläuft. Das Register wird außerdem eine Liste verifizierter DPP-Dienstleister führen (Artikel 3 Buchstabe f). Wie diese Delegation technisch funktionieren wird, ist in den Integrationsleitfäden noch nicht beschrieben. Unabhängig vom gewählten Weg bleibt der Wirtschaftsakteur in vollem Umfang für die Einhaltung der Vorschriften verantwortlich.

Wie funktioniert eine Registrierungsübermittlung?

Der Ablauf besteht aus vier Aufrufen. Sie rufen die Produktgruppen ab, übermitteln und verfolgen dann die Aufgabe über das, was die Kommission die Activity Dashboard API nennt.

POST /api/v1/dpp/submission
Authorization: Bearer <access token>
Idempotency-Key: 7f3c9a2e-batch-2027-02-01-001
Content-Type: application/json

{
  "productGroup": "BATTERIES",
  "productSubGroup": "EV",
  "submissionItems": [
    {
      "uniqueProductIdentifier": "https://example.com/dpp/battery/0001",
      "granularity": "item",
      "batchIdentifier": "xxx-000",
      "modelIdentifier": "yyy-111"
    }
  ]
}

Dieser Body folgt dem offiziellen Beispiel. uniqueProductIdentifier und granularity (item, batch oder model, also Artikel, Charge oder Modell) sind für jedes Element erforderlich; die Chargen- und Modellkennungen sind optional.

Das Register antwortet mit 202 Accepted und einer taskId. Ein 202 bedeutet nur, dass die Anfrage zur Verarbeitung angenommen wurde. Danach fragen Sie GET /api/v1/tasks/{taskId} ab, und wenn Sie wissen müssen, welche Elemente bestanden haben, GET /api/v1/tasks/{taskId}/items, das JSON oder CSV liefert.

Zwei Statusfelder sind wichtig, und sie bedeuten Unterschiedliches. Der status der Aufgabe durchläuft PENDING, PROCESSING, COMPLETED oder ERROR. Nach Abschluss gibt outcomeResult SUCCEEDED oder FAILED an. Eine Aufgabe kann COMPLETED mit dem Ergebnis FAILED sein: Die Verarbeitung hat funktioniert, und Ihre Daten haben die Prüfung nicht bestanden. ERROR ist ein technischer Fehler auf Seiten des Registers.

Es gibt keine Webhooks. Der Leitfaden empfiehlt Polling nach 1, 1, 2, 3, 5, 8, 13, 21, 34 und 55 Sekunden, danach höchstens alle 60 Sekunden, und ein Retry-After-Header hat immer Vorrang vor Ihrem eigenen Zeitplan.

Die Regel, die Ihr Batch-Design prägen sollte, ist die Atomarität. Eine Übermittlung umfasst 1 bis 100 Pässe derselben Produktgruppe und Untergruppe, und wenn auch nur einer davon nicht konform ist, wird keiner registriert, auch nicht die, die bestanden haben. Ein fehlerhafter Datensatz in einem Batch von 100 hält 99 gute zurück. Wir würden jeden Pass vor der Übermittlung lokal gegen die veröffentlichten Schemas validieren, die Batches kleiner halten, solange sich Ihre Daten noch einpendeln, und die fehlerfreien Elemente nach einem Fehlschlag zügig erneut übermitteln.

Der Header Idempotency-Key ist verpflichtend, mit bis zu 128 Zeichen. Ein erneuter Versuch mit demselben Schlüssel liefert die ursprüngliche Aufgabe zurück, statt ein Duplikat zu erzeugen, und genau das wollen Sie nach einem Timeout oder einem 500. Eine geänderte Übermittlung braucht einen neuen Schlüssel; wer einen Schlüssel für andere Inhalte wiederverwendet, erhält einen 409.

Die Fehlercodes sind die üblichen (400, 403, 409, 413, 422, 429, 500), und der Leitfaden gibt für jeden an, ob mit demselben oder einem neuen Schlüssel erneut versucht werden soll. Ein 403 bedeutet meist, dass die Organisation nicht verifiziert ist oder dem Dienstkonto die Registrierungsrolle fehlt.

Was ändert sich, wenn Sie die Pässe selbst hosten?

Batteriepässe enthalten öffentliche und beschränkte Daten, und das Register liest bei der Validierung beide. Liegt der Pass auf Ihrem eigenen Server, muss dieser Server das Register erkennen und ihm mehr zeigen als der Öffentlichkeit.

Ihr Passhost fungiert als OAuth-2.0-Resource-Server. Das Register fragt die UPI zunächst ohne Anmeldedaten ab und erwartet den öffentlichen Pass. Danach fragt es dieselbe URL mit einem Bearer-Token ab, das vom Authentifizierungsdienst der Kommission ausgestellt wurde, und erwartet die öffentlichen plus die beschränkten Daten. Das Token ist kurzlebig (ES384, höchstens 120 Sekunden), trägt den Scope dpp:registry:read und ist an den HTTPS-Origin Ihres Hosts adressiert. Sie validieren es ausschließlich gegen die Schlüssel im veröffentlichten JWKS der Kommission, nie gegen Schlüssel, auf die im Token selbst verwiesen wird.

Die Antwortregeln sind streng. Kein Token: Geben Sie den öffentlichen Pass zurück. Gültiges Token und berechtigter Anfragender: Geben Sie öffentliche plus beschränkte Daten zurück. Ein Token, das vorhanden, aber ungültig ist: Geben Sie 401 zurück, ohne Rückfall auf die öffentliche Ansicht. Gültiges Token mit falschem Scope oder falschem Anfragenden: 403. Senden Sie Vary: Authorization, damit Caches die beiden Versionen getrennt halten, und verwenden Sie TLS 1.2 oder höher. JSON ist das Basisformat der Antwort; JSON-LD und XML werden ebenfalls akzeptiert.

Der Leitfaden beschreibt nur einen Aufrufer, das Register selbst. Er regelt nicht, wie sich Behörden, Recycler oder andere Parteien mit berechtigtem Interesse authentifizieren werden, Sie brauchen für sie also eine eigene Lösung; unser Leitfaden zu den Zugriffsrechten beim digitalen Produktpass erklärt, wer worauf Anspruch hat. Eindeutige Betreiberkennungen werden ebenfalls noch nicht verarbeitet; der Leitfaden plant sie für eine künftige Version.

Wo GS1 Digital Link ins Bild passt

Das Register folgt Weiterleitungen, höchstens drei über die gesamte Auflösung, und es löst die UPI und jede Weiterleitung ohne Anmeldedaten auf, daher muss jeder Schritt öffentlich erreichbar sein. Das ist mit einem Resolver vereinbar. Eine GS1 Digital Link URI auf Ihrer eigenen Domain, etwa https://id.yourbrand.com/01/09520123456788/21/SN0001, ist eine Möglichkeit, jeder Batterie eine dauerhafte HTTPS-Kennung zu geben, die zu ihrem Pass führt und zugleich als QR-Code auf dem Produkt dient. Sie ist nicht vorgeschrieben; jede stabile HTTPS-URL erfüllt die Formatregel der API. Wenn Sie einen Resolver nutzen, zählen Sie die Sprünge: Eine Kette von der QR-Domain über den Resolver und den Hosting-Anbieter bis zur finalen URL verbraucht bereits alle drei. Der Leitfaden rät außerdem, Weiterleitungen nach der Authentifizierung zu vermeiden, damit die berechtigte Anfrage direkt beim Pass ankommt.

Gegen welche Datenmodelle validiert das Register?

Das ZIP der Semantic Data Artifacts enthält die Modelle, die das Register prüft. Heute gibt es nur zwei: ein Kernmodell und ein Batteriemodell, beide in Version 1.0.0, mit Untergruppen-Schemas für EV-, LMT- und Industriebatterien. Jedes liegt als JSON Schema (Draft 2020-12), JSON-LD-Kontexte, SHACL-Shapes und SKOS-Vokabulare vor, dazu ein DCAT-AP-Katalog. Der Leitfaden beschreibt auch XSD, das in dieser Version nicht mitgeliefert wird.

Die Schemas sind nach Zugriffsebene aufgeteilt: eine öffentliche Ansicht (pub) und drei beschränkte Ansichten (res1, res2, res3). Ihr Pass muss dem richtigen Anfragenden die richtigen Felder zeigen, und das Schema sagt Ihnen, welche Felder wo liegen. Das ZIP enthält außerdem Beispielinstanzen, die dem jeweiligen Schema entsprechen und sich gut als erste Test-Fixture eignen.

Vier Serialisierungen werden beschrieben (JSON, JSON-LD, XML und RDF), aber nur JSON ist für die Registrierung verpflichtend, im Einklang mit EN 18216:2026. Der Leitfaden verweist zur Interoperabilität außerdem auf EN 18223:2026. Beide Normen erklären wir im Leitfaden zu den CEN-DPP-Normen, und warum strukturierte Daten wichtig sind, in unserem Leitfaden zum maschinenlesbaren digitalen Produktpass. Artikel 12 der Durchführungsverordnung ergänzt, dass das semantische Repository kostenlos nutzbar ist und über öffentliche APIs verfügt.

Was bringt der Batterie-Leitfaden v3.2 hinzu?

Das Guidance Document: Digital Batteries Passport, data points by category, Version 3.2 vom 19. Oktober 2026, listet 71 Datenpunkte für EV-, LMT- und Industriebatterien auf. Es ist ein Leitfaden und erklärt selbst, nicht rechtsverbindlich zu sein; die Pflichten ergeben sich aus der Batterieverordnung (EU) 2023/1542.

Für jeden Datenpunkt und jede Batteriekategorie gibt es einen Status an: verpflichtend; optional, auszufüllen, wenn die Daten verfügbar sind; falls zutreffend; nur für bestimmte Batterietypen; oder mit Stand Februar 2027 nicht auszufüllen bzw. nicht anzuzeigen. Dieser letzte Status ist für die Planung der nützliche. Die Erklärung zum CO₂-Fußabdruck und das zugehörige Label etwa sind als im Februar 2027 nicht auszufüllen markiert, weil ihr Format noch auf einen Durchführungsrechtsakt wartet, und die Gebrauchsanweisung ist bis zum Omnibus zurückgestellt. Jeder Datenpunkt trägt außerdem eine Zugriffsebene: öffentlich, beschränkt auf Personen mit berechtigtem Interesse, notifizierte Stellen, Behörden der Mitgliedstaaten und die Kommission, oder engere beschränkte Ebenen. Genau diese Ebenen setzen die Schema-Ansichten pub und res um.

Unser Leitfaden zum Batteriepass behandelt die rechtlichen Anforderungen. Für die Integrationsarbeit nutzen Sie v3.2 als Zuordnungstabelle zwischen Ihren Produktdaten und den Schemafeldern.

Was ist entschieden, und was ist noch offen?

Entschieden: die Endpunkte, das Authentifizierungsmodell, die atomare Batch-Regel, das Polling, das Datenmodell für Batterien und die Anforderung, dass Pässe bei der Übermittlung online sind. Die Verifizierung per qualifiziertem Siegel steht in der Durchführungsverordnung selbst.

Mit Stand November 2026 noch offen: wie die Registrierung durch verifizierte Dritte im Namen eines Wirtschaftsakteurs technisch funktionieren wird, Datenmodelle für alles außer Batterien, das Format für den CO₂-Fußabdruck, wie sich andere Parteien gegenüber selbst gehosteten Pässen authentifizieren, und eindeutige Betreiberkennungen. Die Durchführungsverordnung erfasst auch Bauprodukte, Spielzeug und Detergenzien, für die es noch kein Datenmodell gibt; für andere Produkte als Batterien beginnen die Pflichten frühestens 18 Monate nach dem jeweiligen delegierten Rechtsakt. Die Mitgliedstaaten müssen ihre nationalen Registeradministratoren bis zum 18. Februar 2027 benennen (Artikel 7).

Ungereimtheiten in den Dokumenten der Version 1.0

Eine erste Version hat immer Inkonsistenzen, und diese sollten Sie kennen, bevor Sie Code schreiben:

• Der Service-Account-Leitfaden nennt als API-Basis reg.product-passport.ec.europa.eu, während die OpenAPI-Dateien registry.product-passport.ec.europa.eu verwenden (und registry.acc.product-passport.ec.europa.eu für die Abnahmeumgebung). Prüfen Sie den aktuellen Wert im Register, bevor Sie die Produktion konfigurieren.
• Die Grenze von 100 Elementen steht im Leitfaden, wird aber im OpenAPI-Schema nicht erzwungen, sodass ein aus dem Schema generierter Client anstandslos eine Anfrage mit 101 Elementen baut.
• Der Integrationsleitfaden sagt, Fehler liefern die Kennung als traceId, während das OpenAPI-Fehlerschema sie correlationId nennt. Protokollieren Sie beide.
• Die API verwendet den Untergruppencode EV, während die semantischen Artefakte in ihren Pfaden evb verwenden. Ordnen Sie sie explizit einander zu.

Keiner dieser Punkte blockiert die Integration, aber prüfen Sie sie bei jeder neuen Version der Dokumente erneut.

Was Sie jetzt tun sollten

1. Beschaffen Sie ein qualifiziertes elektronisches Siegel bei einem qualifizierten Vertrauensdiensteanbieter, falls Ihr Unternehmen noch keines besitzt, und verifizieren Sie Ihre Organisation im Register. Das hat die längste Vorlaufzeit von allem auf dieser Liste.
2. Melden Sie sich in der Abnahmeumgebung an und benennen Sie einen Administrator, der Dienstkonten anlegen kann.
3. Entscheiden Sie, wo die Pässe liegen: auf Ihrem eigenen Server, der dann die Regeln für die Authentifizierung bei Selbst-Hosting umsetzen muss, oder bei einem Anbieter, der das bereits tut.
4. Legen Sie Ihre UPIs fest. Wählen Sie für jede Batterie ein stabiles HTTPS-URL-Muster, entscheiden Sie sich für die Granularität Artikel, Charge oder Modell, und zählen Sie die Weiterleitungen in der Kette.
5. Ordnen Sie Ihre Daten v3.2 und den Batterie-Schemas zu, Feld für Feld, einschließlich der öffentlichen und beschränkten Ansichten. Markieren Sie, was im Februar 2027 nicht erforderlich ist, damit niemand Zeit damit verschwendet.
6. Validieren Sie lokal, bevor Sie übermitteln, gegen die mitgelieferten JSON Schemas, und gestalten Sie Batches so, dass ein fehlerhafter Datensatz den Rest nicht zurückhält.
7. Bauen Sie den Client sauber: EC-Schlüssel in einem HSM, Token-Erneuerung, reproduzierbare Idempotenzschlüssel, Fibonacci-Polling und die Speicherung jedes Registrierungsnachweises.
8. Führen Sie einen vollständigen Test in der Abnahmeumgebung durch, deutlich vor dem 18. Februar 2027, einschließlich eines fehlgeschlagenen Batches und einer Schlüsselrotation.

Digital Link ist GS1 Solution Partner, und unsere Plattform baut Batterie- und Produktpässe auf einer dauerhaften GS1 Digital Link-Kennung pro Produkt auf, wobei öffentliche und beschränkte Daten aus demselben Datensatz ausgeliefert werden. Wir bereiten unsere eigene Registerintegration vor. Dazu gehören drei getrennte Schritte: unser qualifiziertes elektronisches Siegel zu erhalten, unsere Verifizierung im Register abzuschließen und die API-Anbindung aufzubauen und zu testen. Wir sind noch nicht an das Register angebunden. Wenn Sie Ihre Registerintegration planen oder prüfen möchten, ob Ihre Passdaten die Validierung bestehen, nehmen Sie Kontakt auf, und unser Team prüft Ihren Fall.

Häufig gestellte Fragen

Ist die DPP-Register-API verpflichtend?

Nein. Artikel 8 Absatz 6 der Durchführungsverordnung (EU) 2026/1778 erlaubt die Registrierung über die Benutzeroberfläche oder die API. In der Praxis wird jeder, der mehr als eine Handvoll Pässe registriert, die API nutzen wollen.

Speichert das Register meine Passdaten?

Nein. Es ruft den Pass bei der Übermittlung unter seiner URL ab, um ihn zu validieren, und der Integrationsleitfaden stellt fest, dass es den abgerufenen Inhalt nicht speichert. Der Pass bleibt dort, wo Sie ihn hosten, und deshalb muss er bei der Übermittlung erreichbar sein.

Kann ich für mein Dienstkonto einen RSA-Schlüssel oder ein Client Secret verwenden?

Nein. Dienstkonten authentifizieren sich mit private_key_jwt unter Verwendung von Schlüsseln auf Basis elliptischer Kurven (ES256, ES384 oder ES512). Gemeinsam genutzte Client Secrets und RSA-Schlüssel werden nicht unterstützt.

Was passiert, wenn ein Pass in einem Batch die Validierung nicht besteht?

Die gesamte Übermittlung schlägt fehl, und keiner ihrer Pässe wird registriert. Die Aufgabe wird mit dem Ergebnis FAILED abgeschlossen, und die Ergebnisse pro Element zeigen Ihnen, welche Elemente es verursacht haben. Korrigieren Sie sie und übermitteln Sie erneut mit einem neuen Idempotenzschlüssel.

Brauche ich GS1 Digital Link, um einen Pass zu registrieren?

Nein. Die eindeutige Produktkennung muss eine HTTPS-URL sein, die zum Pass auflöst. Eine GS1 Digital Link URI auf Ihrer eigenen Domain ist eine Möglichkeit, das zu erfüllen, und dient zugleich als QR-Code des Produkts, aber jede stabile HTTPS-URL wird akzeptiert.

Wann müssen Batteriepässe registriert werden?

Für EV-Batterien, LMT-Batterien und Industriebatterien über 2 kWh gilt die Batteriepasspflicht nach der Verordnung (EU) 2023/1542 ab dem 18. Februar 2027. Das Register und seine Abnahmeumgebung sind bereits offen, es bleibt also Zeit, vorher zu testen.