Archiv-Referenzen und Ereignisse

Archivdaten erscheinen erst nach bestätigter Speicherung und nur bei aktiviertem Archivmodul. In einem nachfolgenden Dokument- oder E-Mail-Webhook stehen <<archive.id>>, <<archive.link>>, <<archive.sha256>> und <<archive.retentionFloorUntil>> bereit. Die gleichen Felder erscheinen optional als archive im Eintrag von GET /api/document-deliveries, wenn das abholende Token archive:read besitzt. Bei noch ausstehender Archivierung fehlt der Block; die Abholung bleibt nutzbar. archive.link zeigt absolut auf /api/archive/{id}/download, benötigt weiterhin einen berechtigten Archivzugang und erzeugt keinen öffentlichen Freigabelink. Der Origin stammt aus der konfigurierten SPA_FRONTEND_URL; im Deployment müssen App und API unter diesem Origin über /api erreichbar sein.

Mit dem Webhook-Typ Archiv-Ereignisse wird ein HTTPS-POST-Ziel für einen Mandanten oder Umgebungs-Mandanten eingerichtet. events enthält eine nicht leere Auswahl aus archive.stored, archive.hold-placed, archive.hold-released, archive.share-downloaded und archive.disposed. config enthält beispielsweise { "url": "https://ziel.example/archiv", "method": "POST", "options": { "headers": { "Authorization": "Bearer <<credentials.archiv-token>>" } } }. Der Typ wird unabhängig von Rendering-Prozessen eingerichtet; er braucht keine Zuordnung zu einer Vorlage oder einem Auftrag. Er erscheint nur bei aktiviertem Archivmodul.

Jeder POST enthält id, type, occurredAt, archive sowie clientId, subClientId, renderProcessId, emailProcessId und xmlProcessId. Die vier Archivfelder in archive sind dieselben wie oben. X-Archive-Event-ID wiederholt die stabile id. Der Empfänger sollte diese ID für eine idempotente Verarbeitung speichern: nach einem Netzfehler oder einem Prozessabbruch nach erfolgreichem HTTP-POST kann dasselbe Ereignis erneut eintreffen. Jede 2xx-Antwort bestätigt den Empfang; andere Antworten führen zu automatischen Wiederholungen mit wachsendem Abstand. Ausstehende Ereignisse bleiben gespeichert. Eine deaktivierte Archivfunktion oder ein deaktiviertes Ziel stoppt die Zustellung bis zur erneuten Aktivierung. Änderungen am Ziel gelten für noch ausstehende Ereignisse.

Legal-Hold-Ereignisse folgen erst nach bestätigtem Schutzwechsel, auch bei Massen-Holds. archive.disposed folgt erst nach bestätigter Löschung. archive.share-downloaded meldet den erfolgreichen öffentlichen Dokumentabruf über einen Freigabelink; das bloße Öffnen der Linkseite löst kein Ereignis aus. Der geschützte archive.link ist nach einer Löschung nicht mehr abrufbar.

Für Archivlisten sind renderProcessId, emailProcessId und xmlProcessId als exakte Filter verfügbar. Dieselben Felder stehen unter POST /api/archive/search und POST /api/spa/archive/search in filters zur Verfügung, etwa { "filters": { "renderProcessId": 123 }, "options": {} }. Mandanten-, Umgebungs-Mandanten-, Token- und Prüfergrenzen gelten wie bei der ungefilterten Suche; ein Suchcursor behält seinen ursprünglichen Treffer-Snapshot.