Änderungsprotokoll
Die Entwicklung von Veridyn Monat für Monat — von der ersten Version der Produktpass-Engine bis zur Entwickler-API. Die Datumsangaben bezeichnen den Monat, in dem die Funktion erschienen ist; die wesentlichen Änderungen führen wir hier.
Auch Kontaktnachrichten verfallen jetzt
Eine über das Kontaktformular eingegangene Anfrage (Name, E-Mail, Firma, Nachricht) lag bisher ohne Frist im Admin-Postfach, und die Datenschutzerklärung zeigte an dieser Stelle nur einen Hinweis „z. B. 1 Jahr“. Ab sofort wird eine Anfrage nach 24 Monaten automatisch gelöscht — ausgeführt von derselben geplanten Bereinigung wie beim Scan-Protokoll —, und in der Erklärung steht diese Zahl statt eines Platzhalters. Neben dem Formular steht jetzt auch der kurze Hinweis: wofür wir die Nachricht verwenden, auf welcher Rechtsgrundlage und wie lange wir sie aufbewahren.
Zertifikat-Upload und Lieferanten-Datenanfrage aus dem Code
Zwei Funktionen waren bisher nur im Browser verfügbar, obwohl gerade der maschinelle Weg sie braucht. Der Dokument-Upload: Das Zertifikat-PDF entsteht in einem Dokumentenmanagement oder im Schriftwechsel mit dem Labor, nicht in einem Browser-Tab — ab jetzt lässt es sich über die API in base64 hochladen, herunterladen und löschen. Über den Typ entscheidet der Inhalt, nicht der Dateiname: eine als PDF ausgegebene Datei weisen wir ab. Die Lieferanten-Datenanfrage: Den Link zu starten, mit dem die Weberei oder der Zellhersteller nach ihren Daten gefragt wird, die Einreichung zu prüfen und einzupflegen, geht ebenfalls aus dem Code — so kann ein Beschaffungssystem nicht nur die 500 Pässe hochladen, sondern auch die 500 Datenanfragen starten.
Inkrementelle Synchronisation: nur die Änderungen
Ein ERP kann nicht jede Nacht den gesamten Passbestand durchlesen. Mit dem Parameter <code>updated_since</code> kommen jetzt nur die geänderten Pässe zurück — auf allen Ebenen (Modell, Charge, Einzelstück) — mit Cursor-Paginierung. Mit Cursor und nicht mit Seitenzahl: Die Paginierung nach Seitenzahlen überspringt still Zeilen, wenn sich zwischenzeitlich ein bereits gesehener Eintrag ändert. Auch der archivierte Pass fällt nicht aus der Liste: Er kommt mit dem Status <code>archived</code>, und daran erkennt Ihr System, dass es ihn entfernen muss.
Lebenszyklus, Versionen und Behördenzugang über die API
Was bisher nur in der Oberfläche möglich war, geht jetzt auch aus dem Code: Archivieren und Wiederherstellen (ohne eine neue Version zu erzeugen — eine Sichtbarkeitsänderung ist keine Datenänderung), der Änderungsverlauf mit feldgenauem Unterschied, und die Ausgabe ablaufender Zugriffslinks an eine Behörde oder eine Partei mit berechtigtem Interesse. Auf letzterem liegt bewusst keine Paket-Sperre: Der Behördenzugang ist eine gesetzliche Anforderung, kein Aufpreis-Thema.
PATCH nennt jetzt, was verworfen wurde
Der Endpunkt <code>PATCH /products/{id}</code> führt pro Schlüssel der obersten Ebene zusammen. Senden Sie ein verschachteltes Objekt (etwa <code>dimensions</code>) nur teilweise, gehen die nicht gesendeten Geschwisterfelder verloren — und wo das Objekt kein Pflicht-Unterfeld hat, war die Speicherung bisher erfolgreich, während die Daten still verschwanden. Das Verhalten haben wir absichtlich NICHT geändert (ein vollständiger Austausch kann gewollt sein, und ein Wechsel auf tiefes Zusammenführen würde bestehende Aufrufe rückwirkend brechen), aber die Antwort sagt es jetzt ausdrücklich: <code>dropped_fields</code> listet die verworfenen Felder auf, dazu kommt eine <code>warning</code>. Die vorige Version bleibt in der Änderungshistorie unversehrt und ist wiederherstellbar.
Standardbegriffe in den Maschinendaten eines Einzelstück-Passes
In den Maschinendaten eines Einzelstück-Passes fehlte bisher die GTIN — eine Maschine musste zusätzlich den übergeordneten Pass abrufen, um zu erfahren, zu welchem Produkt das Stück gehört. Der Typ war <code>Product</code>, obwohl <code>IndividualProduct</code> von schema.org genau dies bedeutet: „ein einzelnes, identifizierbares Exemplar eines Produkts“. Seriennummer und Änderungszeitpunkt standen zudem nur unter unseren eigenen <code>dpp:</code>-Begriffen, nicht unter den standardisierten <code>serialNumber</code> und <code>dateModified</code>. Alle vier Punkte sind behoben, und zwar additiv: die bisherigen <code>dpp:</code>-Felder bleiben an ihrem Platz, die standardisierten kommen hinzu — keine bestehende Integration bricht.
Unbekannte Seriennummer: wir sagen, dass wir sie nicht gefunden haben
Wenn jemand eine nicht existierende Charge oder Seriennummer scannt — Tippfehler, beschädigter QR-Code oder Fälschung —, lieferte das System bisher stillschweigend den Modell-Pass. Das ist die schlechteste Antwort: es sah wie ein gültiger Produktpass aus. Jetzt wird die nächstgelegene bekannte Ebene ausgeliefert, und oben auf der Seite steht ein Hinweis, dass die gescannte Kennung nicht gefunden wurde. Maschinelle Anfragen erhalten <code>404</code> mit dem Code <code>unknown_identifier</code> und der Modell-URL; die Seite wird als <code>noindex</code> markiert, damit eine erfundene Kennung nicht in Suchmaschinen gelangt.
Sie sehen es, wenn wir Ihr Konto betreten haben
Für den Support müssen wir gelegentlich ein Konto betreten. Das wurde immer in ein unveränderliches Protokoll geschrieben — allerdings auf unserer Seite, wo Sie es nicht sehen konnten. Ein Versprechen, das man nicht überprüfen kann, ist keines. Ihr eigenes Protokoll finden Sie jetzt in den Einstellungen: wann wir eingetreten sind, wann wir gegangen sind, wie lange es dauerte. Den Namen der Mitarbeiterin oder des Mitarbeiters nennen wir absichtlich nicht — das ist unsere interne Verantwortung —, aber die Tatsache und die Dauer gehören Ihnen. Zusätzlich ist jede Version, die wir in Ihrem Konto gespeichert haben, in der Änderungshistorie gekennzeichnet, sodass nachträglich sichtbar bleibt, dass sie nicht von Ihnen stammt. Dazu haben wir auch das Abmelden korrigiert: es schließt den Eintrag jetzt auf allen Wegen — ein offener Eintrag zeigte bisher für immer „noch im Konto“ an.
Der Import meldet übergroße Dateien verständlich
Eine große oder beschädigte Tabelle lief bisher in das Speicherlimit des Servers, und der Browser erhielt nur eine abgebrochene Antwort — nichts sagte, was schiefging. Uploads werden jetzt an drei Stellen geprüft: Dateigröße (höchstens 16 MB), Anzahl der internen Einträge der Arbeitsmappe und entpackte Größe (höchstens 32 MB). In allen drei Fällen erhalten Sie eine ordentliche, erklärende Fehlermeldung, die auch das Limit nennt. Teilen Sie große Bestände in mehrere Dateien auf — der Import lässt sich mehrfach ausführen.
Maßeinheiten sind jetzt maschinenlesbar
Eine Zahl allein ist noch keine Angabe: <code>ratedCapacity: 2500</code> kann 2500 Ah oder 2500 mAh bedeuten — ein Faktor von tausend. Die Maßeinheit stand bisher nur in der menschenlesbaren Feldbezeichnung; der Schema-Endpunkt nannte sie nicht. Ab jetzt liefert jedes numerische Feld auch ein <code>unit</code>-Feld (<code>GET /api/v1/schema/{category}</code>), und die <a href="/ns/dpp/v1">Vokabular-Seite</a> zeigt sie ebenfalls an. Der wichtigste Fall ist der CO₂-Fußabdruck: bei Batterien energiebezogen (<code>kg CO₂e/kWh</code>), bei Textilien pro Stück (<code>kg CO₂e</code>) — derselbe Feldname, nicht vergleichbare Zahlen. Darauf hat bisher nichts hingewiesen.
Schema-Version: Wir melden, wenn sich der Vertrag ändert
Die Feldliste der Kategorien bewegt sich mit der Gesetzgebung, und bisher wies nichts auf eine Änderung hin — Integrationen gingen still kaputt. Der Schema-Endpunkt liefert jetzt eine Version und einen ETag: Solange Sie eine <code>304</code> erhalten, gibt es nichts zu tun. Der Fingerabdruck entsteht aus dem maschinellen Vertrag (Feld, Typ, Pflichtangabe, Enum, Zugriffsstufe), eine neu formulierte Bezeichnung oder Hilfe löst also keinen Fehlalarm aus. Bei einer nicht rückwärtskompatiblen Änderung kommen zusätzlich die Header <code>Deprecation</code> und <code>Sunset</code>.
Live-Daten von Einzelstücken im Massenverfahren zurückschreiben
Ein Teil der Felder auf Einzelstück-Ebene sind Live-Daten: Gesundheitszustand, Zyklenzahl und Restkapazität der Batterie kommen aus dem BMS. Diese lassen sich jetzt mit einem Aufruf auf bis zu 500 Einzelstück-Pässe zurückschreiben, adressiert über Serien- oder Chargennummer — unsere interne Kennung müssen Sie nicht speichern. Wo sich ein Wert nicht geändert hat, entsteht keine leere Version: Eine tägliche Flotten-Synchronisation füllt den Änderungsverlauf nicht mit Rauschen.
Schutz des GTIN-Eigentums
Eine GTIN entsteht aus dem GS1-Firmenpräfix des Herstellers, und eine Produktkennung in einem fremden Konto führt zu einem irreführenden Pass. Sie können jetzt Ihr eigenes GS1-Firmenpräfix angeben: Das System lässt dann keine GTIN außerhalb davon zu. Bei Konten ohne Präfix bleibt die Bereichsprüfung (Ausschluss der In-Store-, Coupon- und Demo-Bereiche), und jede strittige Kennung kann gemeldet werden — ohne Anmeldung.
Webhooks: identifizierte Ereignisse, Nachholen, erneutes Senden
Ein Wiederholungsversuch bedeutet, dass dasselbe Ereignis mehrfach eintreffen kann. Deshalb erhält jedes Ereignis eine eigene Kennung (im signierten Body und im Header), mit der Duplikate herausgefiltert werden können. War Ihr System dauerhaft nicht erreichbar, ging das Ereignis früher verloren — jetzt ist der vollständige Ereignisverlauf samt Zustellstatus abfragbar, und Sie können dort weitermachen, wo Sie aufgehört haben.
BatteryPass-Konformität: 11/11
Wir bestehen alle 11 Tests der BatteryPass-Ready-Konformitätsprüfung — dreimal hintereinander wiederholt, damit nicht der Zufall entscheidet. Die Prüfung sieht sich keine eingereichte Datei an: Sie spricht das laufende System über das Netz an und misst, ob es sich normgemäß verhält — Lesen über Pass- und Produktkennung, Zugriffsfilterung Feld für Feld, versionierte Änderungen, Hinzufügen und Löschen von Attributen, zurückgezogene Pässe, Berechtigungsprüfung und die Meldung des Inverkehrbringens.
Vollständige JTC24-Abdeckung
Wir können jedes abbildbare Feld des offiziellen EV-Datenmodells ausgeben. Wir mussten es messen, denn ein Schemavalidator beantwortet diese Frage nicht: Zuvor gingen 129 von 211 Feldern hinaus, also 61 % — vierzehn Feldgruppen gab es in unserem Schema schlicht nicht (absoluter CO₂-Fußabdruck, zertifizierte und verbleibende nutzbare Energie, Cadmium-/Blei-Kennzeichnung, Garantiedauer, Datum der Inbetriebnahme, Überladungs- und Tiefentladungsereignisse, Risikoindizes der Lieferkette, Rezyklatanteil je Material). Die Abdeckung wird nun von einem Test bewacht, damit sie nicht unbemerkt zurückfällt.
Normkonforme maschinelle Schnittstelle
Neben unserer eigenen Entwickler-API bedienen wir jetzt auch die Endpunkte der CEN-CENELEC JTC 24 Lebenszyklus-API (EN 18222) — in der Sprache, die der Rest des Batterie-Ökosystems spricht. Mit rollenbasiertem Zugriff und mit den ausgehenden Aufrufen, die das Inverkehrbringen verlangt: eine Kopie an den unabhängigen Backup-Anbieter, danach die Meldung an das Register — in dieser Reihenfolge, denn die Meldung fragt nach der Backup-Kennung.
Rechtliche Vollständigkeit vor dem Speichern
„Speicherbar" und „rechtlich vollständig" sind zweierlei: Das eine sind die wenigen Felder, ohne die kein sinnvoller Datensatz entsteht, das andere ist die Grundlage für Bußgelder. Der Editor warnt jetzt vor dem Speichern, wenn ein Pass rechtlich unvollständig ist — mit Prozentsatz, fehlenden Feldern und Rechtsgrundlage. Er blockiert nicht, denn Daten sammeln sich oft schrittweise an, lässt den Pass aber nicht mehr lautlos hinaus. Das Konformitäts-Dashboard zeigt technische Gültigkeit und rechtliche Vollständigkeit in getrennten Spalten.
Import eines fremden Batteriepasses
Ein JTC24-Dokument von einem anderen Anbieter lässt sich jetzt einlesen, bearbeiten und unverändert zurückgeben. Seine Felder werden auf unsere abgebildet; wofür wir kein eigenes Feld haben, bleibt unangetastet erhalten und wird im Export zurückgegeben. Genau das macht einen Anbieterwechsel praktikabel: Die Daten zu exportieren genügt nicht, die Gegenseite muss sie auch einlesen können — und umgekehrt.
Feldanzahl je Abschnitt
Ein Batteriepass hat sehr viele Felder. Jede Abschnittsüberschrift zeigt jetzt, wie viele Felder sie enthält, wie viele davon zum Speichern nötig und wie viele rechtlich verpflichtend sind — so müssen Sie nicht mehr jeden Abschnitt aufklappen, um zu sehen, wo noch Arbeit wartet.
Laden Sie jede Version herunter
Von jeder Pass-Version entsteht eine unveränderliche, hash-gestempelte Momentaufnahme. Jede davon lässt sich aus der Versionshistorie als JSON herunterladen — Ihre Daten mitzunehmen ist jetzt ein Klick, kein Versprechen. Über den Behörden-Zugriffslink erreicht sie auch die Marktüberwachung.
Die vollständige Kette aus der Oberfläche
Ein Einzelstück lässt sich jetzt direkt unter einer Fertigungscharge anlegen — es übernimmt die Chargenkennung, sodass der aufgedruckte QR-Code die vollständige Kette Modell → Charge → Stück auflöst. Chargen- und Stückpässe lassen sich zudem jederzeit archivieren und wiederherstellen: Löschen gibt es nicht, denn ein gedruckter QR-Code darf nie einen 404 liefern.
Unbegrenzte Chargen- und Stückpässe
Die Tarife messen ab sofort nur noch die Zahl der Modellpässe: Pässe auf Chargen- und Stückebene sind in jedem kostenpflichtigen Tarif unbegrenzt (Fair Use). Welche Ebene Sie brauchen, entscheidet die für Sie geltende Verordnung — die Batterieverordnung schreibt ab dem 18. Februar 2027 die Stückebene vor —, nicht unsere Preisliste.
Warnung bei veralteten Stückpässen
Chargen- und Stückpässe bewahren eine Momentaufnahme der Modelldaten zum Zeitpunkt der Erstellung (darauf beruht die Beweiskraft der Hash-Kette). Ab sofort erfassen wir, aus welcher Modellversion sie stammen: Wenn Sie später am Modell einen Fehler korrigieren, zeigt das System an, wie viele ausgegebene Pässe veraltet sind, und alle lassen sich mit einem Klick aktualisieren. Hat sich dagegen das Produkt selbst geändert (z. B. ein neuer Lieferant), bleiben die Daten der früheren Stücke unangetastet — sie waren zu ihrer Zeit korrekt.
Offenes Beta-Programm
Jeder kann mitmachen: alle Funktionen kostenlos bis zu 100 Modellpässen, ohne Zeitlimit pro Konto. Am Ende der Beta erhalten die frühen Konten einen dauerhaften Founder-Rabatt.
Entwickler-REST-API + interaktive Referenz
OpenAPI-3.1-Spezifikation, herunterladbare Postman-Kollektion, Schlüssel mit Geltungsbereich (Vollzugriff oder nur Lesen), Rate Limit pro Minute, Idempotenzschlüssel sowie signierte und automatisch wiederholte Webhooks — mit einer navigierbaren, durchsuchbaren API-Referenz.
Warnung bei Fälschungsverdacht
Wird der QR-Code eines einzelnen (serialisierten) Produkts aus vielen verschiedenen Ländern gescannt — was bei einem physischen Stück ungewöhnlich ist —, meldet das System einen Klonverdacht (Warnung + Webhook).
Datenportabilität und Kontinuität
Export jederzeit (JSON-LD / GS1 Digital Link) ohne Exportsperre, dazu eine Fortführungsgarantie — die QR-Codes sterben auch dann nicht, wenn Sie uns verlassen.
Bereitschaft für das EU-DPP-Register
Feld für die Zolltarifnummer (CN), „registerbereit“-Markierungen und eine Schritt-für-Schritt-Anleitung zur eIDAS-Authentifizierung für das zentrale EU-Register.
Gestufter Zugriff + teilbare Token
Öffentliche Ebene / Ebene für berechtigtes Interesse / Behördenebene, mit teilbaren, ablaufenden Zugriffslinks — die Kontrolle über sensible Daten bleibt bei Ihnen.
Datenabfrage bei Lieferanten
Fordern Sie Daten und Dokumente bei Ihren Lieferanten über einen ablaufenden Link ohne Anmeldung an und übernehmen Sie sie mit einem Klick in das Produkt.
Dokumentenablage + Hash-Kette
Hängen Sie Compliance-Dokumente (Zertifikate, Datenblätter) an den Produktpass an; zu jeder Version entsteht eine kryptografische Hash-Kette — nachweislich unveränderte Daten.
Scan-Analytik
Scan-Statistik nach Land, Gerät und Zeit im Dashboard, mit Meilenstein-Webhook — sehen Sie, wo und wann Ihre Produkte angesehen werden.
24 EU-Sprachen im Produktpass
Der öffentliche Produktpass erscheint in allen 24 EU-Amtssprachen, angepasst an die Sprache des Besuchers — mit einer schlüsselbasierten Übersetzungs-Engine, keine maschinelle Fehlübersetzung.
Wissensdatenbank + DPP-Bereitschaftstest
Datengestützte Leitfäden zur DPP-Regulierung (ESPR, Fristen, Sanktionen) und ein kostenloser Bereitschaftstest, der zeigt, wo Sie bei der Compliance stehen.
Live-Demo zum Ausprobieren
Ein ohne Registrierung testbares Demo-Konto mit Musterdaten — damit Sie schon vor der Anmeldung sehen, wie das System aussieht und funktioniert.
Abrechnungssystem (während der Beta inaktiv)
Tarife Free / Starter / Pro / Business / Enterprise, Testphase, Stripe Embedded Checkout, MwSt.-Behandlung und zusätzliches Passkontingent über den Tarif hinaus — eingebaut, während der Beta jedoch inaktiv (alle erhalten kostenlosen Vollzugriff).
Admin-Konsole
Interne Betriebskonsole: Betriebskennzahlen, protokollierter Supportzugriff, Nachrichteneingang und Kontoverwaltung an einem Ort.
E-Mail-Benachrichtigungen + Passwort-Zurücksetzung
Begrüßungs- und Kontakt-E-Mails sowie ein sicheres Zurücksetzen des Passworts — über eigenes SMTP, mit zuverlässiger Zustellung.
Versionierte Pässe + Änderungshistorie
Jede Änderung erzeugt eine neue Version, mit vollständiger Änderungshistorie und einem „Aktualisiert“-Datum — der Produktpass ist jederzeit prüfbar.
Geführter Produktpass-Editor
Fortschrittsring, in Abschnitte gegliedertes Formular und „Hier starten“-Markierungen — die EU-Pflichtfelder Schritt für Schritt ausfüllen, ohne Fehlgriff.
Massenimport in mehreren Formaten
Massenimport von Produkten aus CSV-, XLSX-, JSON- und XML-Dateien, mit automatischer Feldzuordnung — ein großer Katalog in wenigen Minuten.
Die Produktpass-Engine
Veridyn startet: schemagesteuerte digitale EU-Produktpässe ohne Programmierung — Kategorievorlagen (Batterie, Textil, Möbel…), QR-Code und Passseite für jedes Produkt.
GS1 Digital Link + JSON-LD + einheitliches Design
Standardbasierter öffentlicher Produktpass: GS1 Digital Link URLs, strukturierte JSON-LD-Daten für Suchmaschinen und Maschinen sowie ein einheitliches helles/dunkles Design.