Öffentliche API und Webhooks integrieren

Zweck und Einsatzbereich

Der Arbeitsbereich Public API verbindet externe Systeme kontrolliert mit ausgewählten NeuraPort-Daten. ADMIN und MANAGER können dort beziehungsweise unter Einstellungen → API & Webhooks:

API-Schlüssel mit begrenzten Scopes erstellen, auflisten und widerrufen,
HTTPS-Ziele für ausgehende Webhooks anlegen, testen und löschen,
Schlüssel und Signatur-Secret unmittelbar nach der Anlage genau einmal übernehmen.

Die öffentliche API ist nicht anonym. Sie unterstützt im geprüften Stand ausschließlich das Auflisten und Lesen begrenzter Aktenfelder, das Lesen zugehöriger Trackingereignisse sowie das Anlegen einer Ratenanfrage. Sie ist keine vollständige Fernsteuerung des TMS und bietet keine allgemeine Schreibfunktion für Akten, Container, Dokumente oder Rechnungen.

Webhooks arbeiten umgekehrt: NeuraPort sendet ein Ereignis als signierte JSON-Nachricht an ein externes HTTPS-Ziel. Der sichtbare Bereich bietet derzeit shipment.created und shipment.status_changed an. Belegt ist shipment.created jedoch nur für eine Akte, die aus einem Angebot erzeugt wird. Für allgemeine Aktenanlagen und shipment.status_changed ist keine durchgängige Webhook-Auslösung belegt. Behandeln Sie diese Auswahl daher bis zu einem Ende-zu-Ende-Test nicht als vollständigen Ereignisvertrag.

Voraussetzungen und Berechtigungen

Der Mandant benötigt das Modul Public API. Der verwaltende Benutzer muss ADMIN oder MANAGER sein und das Modul in seiner aktuellen Organisationseinheit schreibend verwenden dürfen. Plattformadministratoren und andere Rollen erhalten keinen Verwaltungszugriff; andere interne Rollen sehen im Public-API-Arbeitsbereich nur den Hinweis, dass Schlüssel und Webhooks Administratoren oder Managern vorbehalten sind.

Produktive Integrationen dürfen ausschließlich im bestätigten Betriebsmodus ENFORCE freigegeben werden. AUDIT und OFF sind keine Produktivfreigabe. Lassen Sie Modus, Lizenz-, Rollen- und OE-Grenzen vor der Inbetriebnahme durch den Plattformbetrieb dokumentiert abnehmen.

Aufgabe	Erforderlicher Zugriff
API-Schlüssel und Webhooks verwalten	ADMIN oder MANAGER, schreibende Public-API-Lizenz in der aktuellen Organisationseinheit
Aktenliste über API lesen	Aktiver API-Schlüssel mit shipments:read, Public-API-Leselizenz und mindestens Ocean Export oder Ocean Import auf Mandantenebene
Einzelne Akte lesen	Aktiver API-Schlüssel mit shipments:read; Nutzung nur im freigegebenen Mandanten-, OE-, Lizenz- und Rollenprozess
Trackingereignisse lesen	Aktiver API-Schlüssel mit tracking:read; Nutzung nur im freigegebenen Mandanten-, OE-, Lizenz- und Rollenprozess
Ratenanfrage anlegen	Aktiver API-Schlüssel mit rate-requests:write, schreibende CRM-Lizenz und aktive Standard-Organisationseinheit
Webhook empfangen	Erreichbares HTTPS-Ziel, sicher gespeichertes Signatur-Secret und implementierte Signatur-/Dublettenkontrolle

API-Schlüssel, Webhook-Ziele und Auslieferungsprotokolle sind per Datenbankrichtlinie und Abfrage auf den Mandanten begrenzt. Der öffentliche Datenzugriff setzt nach erfolgreicher Schlüsselerkennung ebenfalls den Mandantenkontext und filtert Akten ausdrücklich nach diesem Mandanten.

Betriebsgrenze: Verwenden Sie API-Schlüssel ausschließlich für den ausdrücklich freigegebenen Mandanten-, Organisations-, Lizenz- und Rollenumfang. Ein clientseitiger Filter ist keine Sicherheitsgrenze. Integrationen mit getrennten Niederlassungen oder eingeschränkten Datenbereichen dürfen erst nach einer dokumentierten Produktivabnahme der serverseitigen Scope- und Lizenzprüfung aktiviert werden.

Schritt-für-Schritt-Anleitung

API-Schlüssel anlegen und sicher übergeben

Öffnen Sie den Arbeitsbereich Public API oder Einstellungen → API & Webhooks.
Erfassen Sie unter API-Keys einen eindeutigen technischen Namen, der System, Zweck und Umgebung erkennen lässt, aber keine Zugangsdaten enthält.
Aktivieren Sie nur die benötigten Scopes:
- shipments:read für begrenzte Aktenübersicht und Akteneinzelabruf,
- tracking:read für Trackingereignisse einer Akte,
- rate-requests:write zum Anlegen neuer Ratenanfragen.
Wählen Sie API-Key erstellen. Kopieren Sie den vollständigen Schlüssel aus Neuer API-Key — wird nur EINMAL angezeigt unmittelbar in einen freigegebenen Secret-Manager. Nehmen Sie ihn nicht in Screenshots, Tickets, Quellcode, Browsernotizen oder Chatnachrichten auf.
Wählen Sie Verstanden, ausblenden, sobald die sichere Ablage kontrolliert wurde. Später zeigt NeuraPort nur noch Präfix, Scopes, letzte Nutzung und Status.
Testen Sie mit einem synthetischen Datensatz zuerst eine Operation innerhalb des kleinsten Scopes und anschließend einen sicher erwarteten Scopefehler. Ein erfolgreicher Aufruf belegt nicht automatisch die OE- oder Fachmodulbegrenzung aller anderen Operationen.

Die Oberfläche bietet kein Ablaufdatum und keine direkte Rotation an, obwohl ein Ablaufdatum technisch unterstützt wird. Für eine kontrollierte Rotation erstellen Sie einen neuen Schlüssel, stellen das externe System um, prüfen dessen Nutzung und widerrufen danach den alten Schlüssel. Wählen Sie beim alten Eintrag Widerrufen und bestätigen Sie den Hinweis. Ein Widerruf ist sofort wirksam; ein versehentlicher Widerruf lässt sich nicht zurücknehmen.

Öffentliche API kontrolliert verwenden

Übergeben Sie den Schlüssel ausschließlich über den vorgesehenen Authentifizierungsheader. Die Oberfläche nennt Bearer-Authentifizierung oder X-API-Key; legen Sie ihn niemals in die URL.
Verwenden Sie die Aktenliste nur für die fachlich freigegebenen Export- oder Importrichtungen. Sie liefert pro Seite höchstens 200 nicht archivierte Akten, aber keine Container, Dokumente, Beteiligtenadressen oder Finanzdaten.
Beachten Sie, dass der angezeigte Wert total technisch nur die Anzahl der aktuell gelieferten Seite darstellt, nicht die Gesamtzahl aller Treffer. Paginieren Sie bis zu einer leeren oder kleineren Seite.
Beim Akteneinzelabruf erhalten Sie Aktennummer, Referenz, Status, Schiff, Reise, Booking- und B/L-Nummer sowie ETD und ETA. Verwenden Sie diese Daten nur für den vereinbarten Zweck und behandeln Sie auch Referenznummern als vertrauliche Geschäftsdaten.
Trackingereignisse liefern Transportart, Ereigniscode und -zeitpunkt, Ort, erwartete Ankunft und Provider. Der Weg kann auch Ereignisse einer archivierten Akte liefern; filtern Sie archivierte Vorgänge nicht allein anhand des Listenverhaltens aus.
Beim Anlegen einer Ratenanfrage übermitteln Sie Transportart, Ursprung, Ziel, Menge und optional Equipment, Wunschtermin, Serviceumfang und Notiz. Wiederholen Sie einen unklar beantworteten Schreibaufruf nicht automatisch: Ein fachlicher Idempotenzschlüssel ist dafür nicht vorhanden und kann eine zweite offene Anfrage erzeugen.
Begrenzen Sie Abrufrate und Parallelität im externen Client. Für diese öffentliche API ist keine eigene serverseitige Ratenbegrenzung belegt.

Webhook-Ziel einrichten, prüfen und ablösen

Stellen Sie ein öffentlich erreichbares HTTPS-Ziel bereit. NeuraPort blockiert lokale, private, Link-Local- und bekannte Metadatenziele sowohl bei der Anlage als auch vor dem Versand.
Wählen Sie im Bereich Webhooks mindestens ein sichtbares Ereignis und tragen Sie die Ziel-URL ein. Verwenden Sie getrennte Ziele für Test und Produktion.
Wählen Sie Webhook erstellen. Speichern Sie das Signatur-Secret — wird nur EINMAL angezeigt sofort im Secret-Manager des Empfängers und blenden Sie es anschließend aus.
Der Empfänger muss die HMAC-SHA-256-Signatur über die unveränderten empfangenen Body-Bytes berechnen und zeitkonstant mit X-NeuraPort-Signature vergleichen. Verarbeiten Sie die JSON-Nachricht erst danach.
Verwenden Sie X-NeuraPort-Event-Id als Dublettenschlüssel und speichern Sie bereits verarbeitete IDs. Der Header X-NeuraPort-Event bezeichnet den Ereignistyp. Die Signatur enthält keinen separat zu prüfenden Zeitstempel; setzen Sie deshalb zusätzlich eigene Annahme-, Aufbewahrungs- und Replay-Regeln um.
Wählen Sie beim Ziel Test. Dieser Test sendet ein neutrales ping und beweist Erreichbarkeit sowie Signaturprüfung, aber nicht das Payloadschema oder die Auslösung eines abonnierten Geschäftsereignisses.
Prüfen Sie Letzte Auslieferung und Fehler. Die sichtbare Zahl ist ein fortlaufender Fehlerzähler und wird nach einem späteren Erfolg nicht zurückgesetzt. Einzelne Auslieferungen, Antworttexte, Versuchszeiten und der nächste Wiederholungszeitpunkt sind in der aktuellen Oberfläche nicht sichtbar.
Für eine Secret- oder Zielrotation legen Sie ein neues Ziel an, prüfen es und schalten den Empfänger kontrolliert um. Löschen Sie das alte Ziel erst danach. Löschen entfernt auch die zugehörigen Auslieferungsprotokolle; sichern Sie erforderliche Betriebsnachweise vorher außerhalb von NeuraPort.

Feldreferenz

Feld	Pflicht	Bedeutung	Validierung
API-Key-Name	Ja	Wiedererkennbare Bezeichnung des externen Systems und Zwecks	1 bis 150 Zeichen; führende oder nachgestellte Leerzeichen werden in der Oberfläche entfernt.
API-Key	Einmalig	Vollständiges Authentifizierungsgeheimnis	Wird nur bei Anlage angezeigt und danach nur als Hash gespeichert. Sicher kopieren und anschließend ausblenden.
Präfix	Automatisch	Sichtbarer Anfang zur Zuordnung eines Schlüssels	Kein verwendbarer Schlüssel; nicht als alleiniger Sicherheitsnachweis nutzen.
Scopes	Für Nutzung ja	Erlaubte API-Funktionsgruppen	Oberfläche bietet shipments:read, tracking:read und rate-requests:write. Ein Schlüssel ohne passenden Scope erhält 403.
Ablaufdatum	Nein	Zeitpunkt, nach dem der Schlüssel nicht mehr akzeptiert wird	Technisch unterstützt, im sichtbaren Formular aber nicht erfassbar. Ohne technischen Provisionierungsprozess laufen neue UI-Schlüssel unbefristet bis zum Widerruf.
Zuletzt genutzt	Automatisch	Zeitpunkt der letzten erfolgreichen Schlüsselauthentifizierung	Wird bereits vor der fachlichen Operation aktualisiert; belegt daher nicht deren Erfolg.
Status	Automatisch / Aktion	Aktiv oder Widerrufen	Nur aktive, nicht abgelaufene Schlüssel authentifizieren. Widerruf ist nicht rückgängig zu machen.
Webhook-URL	Ja	Externes HTTPS-Ziel für ausgehende JSON-Nachrichten	Maximal 1.000 Zeichen, muss mit HTTPS beginnen, öffentlich auflösbar sein und darf nicht in blockierte Netzbereiche zeigen.
Ereignisse	Ja im sichtbaren Formular	Welche Ereignistypen an das Ziel gesendet werden sollen	Sichtbar sind shipment.created und shipment.status_changed; nur der erstgenannte Teilweg ist eingeschränkt belegt.
Signatur-Secret	Einmalig	Gemeinsames Geheimnis für die HMAC-SHA-256-Prüfung	Wird bei Anlage einmal angezeigt und bei neuen Zielen verschlüsselt gespeichert. Keine erneute Anzeige oder direkte Rotation.
Event-ID	Automatisch	Stabile Kennung einer Auslieferung und ihrer Wiederholungen	Empfänger muss sie idempotent behandeln. NeuraPort verhindert je Ziel dieselbe gespeicherte Event-ID doppelt.
Letzte Auslieferung	Automatisch	Zeitpunkt des letzten erfolgreichen 2xx-Versands an das Ziel	Kein Nachweis für ein bestimmtes Ereignis; Detailhistorie fehlt im Frontend.
Fehler	Automatisch	Kumulierte Zahl fehlgeschlagener Zustellversuche am Ziel	Wird bei späterem Erfolg nicht auf null gesetzt und unterscheidet keine Ereignisse.
Auslieferungsstatus	Systemseitig	PENDING, SUCCESS oder FAILED je technischem Zustellprotokoll	In der aktuellen Hauptoberfläche nicht als Liste sichtbar.

Status und mögliche Übergänge

API-Schlüssel

Ausgangszustand	Aktion oder Ereignis	Ergebnis
Noch kein Schlüssel	API-Key erstellen	Aktiv; Klartext wird einmal angezeigt, danach nur Metadaten.
Aktiv, nicht abgelaufen, Scope vorhanden	Authentifizierung	Schlüssel wird akzeptiert und Zuletzt genutzt aktualisiert; Fach- und Lizenzprüfung kann danach noch scheitern.
Aktiv, Scope fehlt	Operation	403 wegen fehlendem Scope; Schlüssel bleibt aktiv.
Aktiv, Ablaufdatum erreicht	Authentifizierung	401; Schlüssel bleibt in der Liste, wird aber nicht akzeptiert.
Aktiv	Widerrufen	Widerrufen; alle weiteren Authentifizierungen mit diesem Schlüssel scheitern.

Webhook-Auslieferung

Ausgangszustand	Aktion oder Ereignis	Ergebnis
Ziel angelegt	Test	Ein einmaliges, signiertes ping wird sofort versucht.
Auslieferung PENDING	Ziel antwortet mit 2xx	SUCCESS, Auslieferungszeit wird gespeichert.
Auslieferung PENDING	Nicht-2xx, Timeout oder Transportfehler	Bleibt bis zum fünften Versuch PENDING und erhält einen exponentiell späteren Wiederholungszeitpunkt.
Fünfter Versuch schlägt fehl	Auslieferung	FAILED; keine weitere automatische Zustellung aus diesem Datensatz.
Ziel wird als unsicher erkannt oder Secret ist nicht lesbar	Zustellversuch	FAILED; Ziel kann technisch deaktiviert werden.
Ziel gelöscht	Löschen	Ziel und seine Auslieferungsprotokolle werden entfernt.

Die Wiederholungslogik ist vorbereitet, aber im geprüften Stand ist weder ein automatisch laufender Worker noch ein sichtbarer Knopf zur Verarbeitung fälliger Versuche belegt. Nach einem ersten Fehler darf daher nicht davon ausgegangen werden, dass die geplanten Wiederholungen tatsächlich ohne Betriebsintegration stattfinden.

Was im Hintergrund passiert

NeuraPort erzeugt API-Schlüssel mit einem erkennbaren Präfix und einem kryptografisch zufälligen Anteil. In der Datenbank liegen nur Präfix und Hash, nicht der Klartext. Bei jedem API-Aufruf wird der Schlüssel zunächst in einem privilegierten Suchkontext anhand seines Hashs gefunden, auf Aktivität und Ablauf geprüft, Zuletzt genutzt gespeichert und danach auf den Mandantenkontext des Schlüssels umgestellt. Tabellen für Schlüssel, Webhook-Ziele und Zustellungen besitzen zusätzlich erzwungene Mandantentrennung.

Die öffentliche API verbindet Schlüssel-Scopes mit fachlichen Modul-, Mandanten- und Organisationsfreigaben. Der konkrete Freigabeumfang muss für jede verwendete Lese- und Schreiboperation sowie für ausgehende Webhooks in der vorgesehenen Produktivkonfiguration abgenommen werden. Ein erfolgreicher Einzeltest ersetzt diese Abnahme nicht. Schlüssel und Ziele dürfen nach Änderungen an Lizenz, Rolle oder Organisation erst wieder verwendet werden, wenn der freigegebene Umfang erneut bestätigt ist.

Ratenanfragen werden einer aktiven Organisationseinheit zugeordnet. Die Integration darf dafür nur den vorgesehenen, aktuell freigegebenen Prozess verwenden; technische Direktwege oder nachgelagerte Clientfilter sind keine zulässige Scope-Steuerung.

Neue Webhook-Secrets werden verschlüsselt gespeichert. Der Versand serialisiert die gespeicherte JSON-Nutzlast kompakt und signiert exakt diese Bytes per HMAC-SHA-256. Neben Signatur, Ereignistyp und Ereignis-ID wird kein eigener signierter Zeitstempelheader versendet. Der Empfänger muss Rohdaten vor JSON-Normalisierung prüfen und die Ereignis-ID dauerhaft gegen Wiederholung sichern.

Eine Zustellung wird vor dem Netzaufruf als Outbox-Datensatz gespeichert. Pro Ziel und Event-ID besteht eine Eindeutigkeitsregel. Bei Fehlern sind höchstens fünf Versuche mit wachsendem Abstand vorgesehen. Mehrere Verarbeiter verwenden Datenbanksperren und einen fünfminütigen Lease. Bei gleichzeitigem erstmaligem Dispatch derselben Event-ID ist der Ablauf jedoch nicht vollständig abgesichert: Die Vorabprüfung und das Einfügen sind getrennt, und ein Eindeutigkeitskonflikt wird nicht kontrolliert zurückgesetzt.

Webhook-Payloads und bis zu 2.000 Zeichen einer fehlerhaften Antwort werden im Zustellprotokoll gespeichert. Darin können Akten-, Angebots-, Tracking-, Rechnungs- oder Betragsreferenzen vorkommen. Zielsystem, Aufbewahrung, Zugriffsrechte und Löschkonzept müssen daher wie für andere vertrauliche Betriebsdaten festgelegt werden. Die Daten werden für diesen operativen Versand nicht anonymisiert.

Die technische Ereignisschicht kann neben dem sichtbaren shipment.created weitere Ereignisse aus Angebot, Tracking und Rechnungsabgleich versenden. Diese Ereignisse sind im sichtbaren Formular nicht auswählbar. Umgekehrt ist der sichtbare Typ shipment.status_changed nicht mit dieser Webhook-Schicht verdrahtet. Verwenden Sie keine leere oder frei erfundene Ereignisliste als Workaround: Die technische Schnittstelle interpretiert eine leere Liste als Abonnement aller Ereignisse.

Tests belegen die einmalige Speicherung eines Ereignisses bei sequenzieller Wiederholung, HMAC-Signaturheader, einen fehlerhaften und anschließend erfolgreichen Wiederholungsversuch, verschlüsselte Speicherung neuer Secrets sowie die Sperre interner oder lokaler Zieladressen. Vor der Produktivfreigabe fehlen weiterhin vollständige Ende-zu-Ende-Nachweise für automatischen Retry-Betrieb, Ratenbegrenzung, gleichzeitige Eventdubletten, Schlüsselrotation, alle sichtbaren Webhook-Ereignisse, den produktiven Empfänger sowie die serverseitige Scope- und Lizenzprüfung über alle freigegebenen Mandanten- und Organisationseinheiten.

Typische Fehler und Lösungen

Meldung oder Beobachtung	Ursache	Lösung
API-Keys konnten nicht geladen werden oder Webhooks konnten nicht geladen werden	Sitzung, Public-API-Lizenz, Rolle oder Serverzugriff fehlt.	Aktuelle Organisationseinheit, Rolle und Modulstatus prüfen; keine zweite Verwaltung außerhalb des Mandanten verwenden.
Bitte einen Namen angeben	API-Key-Name ist leer.	Eindeutigen technischen Zwecknamen ohne Secret erfassen.
API-Key konnte nicht erstellt werden	Lizenz, Rolle, Eingabe oder Serververarbeitung ist fehlgeschlagen.	Modulzugriff und aktuelle Einheit prüfen; keinen Schlüssel über unsichere Behelfswege erzeugen.
Vollständiger Schlüssel ist nicht mehr sichtbar	Klartext wurde nach der einmaligen Anzeige verworfen.	Neuen Schlüssel erstellen, extern umstellen und alten kontrolliert widerrufen. Der alte Klartext kann nicht wiederhergestellt werden.
Kopieren fehlgeschlagen	Browser verweigert Zwischenablagezugriff.	Keine Chat- oder Ticketkopie verwenden; sicheren Secret-Manager in einer freigegebenen Umgebung öffnen und Vorgang kontrolliert wiederholen.
Ungültiger oder fehlender API-Key	Schlüssel fehlt, ist falsch, widerrufen oder abgelaufen.	Verwendeten Secret-Eintrag und Status anhand des Präfixes prüfen; Schlüssel nicht protokollieren.
API-Key fehlt der Scope: …	Für die gewünschte Operation fehlt der genaue Scope.	Neuen Schlüssel mit kleinstmöglichem passenden Scope erstellen und alten nach Umstellung widerrufen.
Daten außerhalb des freigegebenen Bereichs erscheinen	Die produktive Mandanten-, OE-, Lizenz- oder Rollenfreigabe ist nicht nachgewiesen.	Integration stoppen, Schlüssel widerrufen und serverseitige Scope- und Lizenzprüfung abnehmen lassen; keinen Clientfilter als Sicherheitsgrenze behandeln.
Zugriffsverhalten ist zwischen Operationen uneinheitlich	Der freigegebene Integrationsumfang ist nicht vollständig oder die Produktivabnahme fehlt.	Nicht als Teilfreigabe interpretieren; Integration stoppen und alle verwendeten Operationen gemeinsam prüfen lassen.
Keine aktive Standard-Organisationseinheit konfiguriert	Ratenanfrage kann keiner aktiven Standard-Einheit zugeordnet werden.	Standard-Einheit administrativ festlegen und danach genau einmal erneut senden.
Doppelte offene Ratenanfrage	Schreibaufruf wurde nach unklarer Antwort wiederholt; Idempotenzschlüssel fehlt.	Vor Wiederholung anhand fachlicher Referenzen suchen und Dublette kontrolliert bereinigen lassen.
Die Webhook-URL muss mit https:// beginnen	Ziel verwendet kein HTTPS.	Öffentliches TLS-Ziel mit gültigem Zertifikat bereitstellen.
Webhook-URL nicht erlaubt	Ziel ist lokal, privat, Link-Local, Metadatenadresse oder nicht auflösbar.	Kein internes Ziel freischalten; einen kontrollierten öffentlichen Relay-Endpunkt mit Zugriffsschutz verwenden.
Bitte mindestens ein Event auswählen	Im sichtbaren Formular ist kein Ereignis gewählt.	Nur fachlich benötigtes, belegtes Ereignis wählen. Keine leere Wildcard-Liste technisch erzwingen.
Test fehlgeschlagen oder Test-Auslieferung fehlgeschlagen	Ziel antwortet nicht mit 2xx, ist nicht erreichbar oder Signatur-/TLS-Verarbeitung scheitert.	Zielprotokoll, TLS und Rohbody-Signatur prüfen; Test erst danach wiederholen.
Test erfolgreich, aber Geschäftsereignis fehlt	ping prüft nur Zustellung; das gewählte Ereignis ist möglicherweise nicht verdrahtet.	Mit synthetischem Ende-zu-Ende-Ereignis testen. shipment.status_changed derzeit nicht als funktionsfähig voraussetzen.
Fehlerzähler bleibt nach Erfolg erhöht	Zähler ist kumulativ und wird nicht zurückgesetzt.	Letzten erfolgreichen Zeitpunkt und externe Empfängerlogs gemeinsam bewerten.
PENDING bleibt ohne weiteren Versuch	Kein belegter automatischer Retry-Worker verarbeitet fällige Zustellungen.	Plattformbetrieb einschalten; Ereignis nicht manuell duplizieren und Retry-Betrieb technisch herstellen.
Signatur stimmt nicht	Empfänger hat JSON vor der Prüfung neu formatiert, falsches Secret oder falsche Bytes verwendet.	Exakte Rohbytes prüfen, HMAC-SHA-256 verwenden und zeitkonstant vergleichen.
Dasselbe Ereignis trifft erneut ein	Zustellung wurde wiederholt oder erneut abgespielt.	Event-ID idempotent speichern und bereits verarbeitete IDs ohne zweite Fachwirkung bestätigen.
Widerruf fehlgeschlagen oder Löschen fehlgeschlagen	Objekt gehört nicht zum Mandanten, ist bereits entfernt oder Zugriff fehlt.	Liste neu laden, Mandanten- und Rollenbezug prüfen; keine fremden IDs verwenden.