Druckversand

Druckversand zeigt alle Briefe, die Output.Rocks über die Webhook-Typen Binect oder E-POSTBUSINESS an einen Druckdienstleister übergeben hat. Die Seite dient als Monitoring- und Eingriffsfläche für Uploads, Provider-Status, Fehler, Kosten und technische Rohantworten.

Voraussetzungen

Der Druckversand entsteht aus Webhooks. Legen Sie unter Webhooks einen passenden Typ an:

Nur PDF-Dateien werden an die Druckdienstleister übergeben. Bei E-Mail-Webhooks werden alle PDF-Anhänge des E-Mail-Prozesses einzeln als Drucksendung angelegt.

Ablauf

1. Ein Dokument- oder E-Mail-Prozess erreicht seine Webhook-Phase und führt einen Binect- oder E-POSTBUSINESS-Webhook aus.
2. Output.Rocks legt pro PDF eine Drucksendung an, merkt sich Provider, Umgebung, Dateiname, Webhook, Quelle und den zugehörigen Render- oder E-Mail-Prozess.
3. Der Upload läuft asynchron über den Workflow print_delivery. Der übergeordnete Dokument- oder E-Mail-Prozess wartet, bis alle zugehörigen Drucksendungen vom Provider angenommen wurden.
4. Nach der Annahme synchronisieren geplante Jobs oder der Button Status synchronisieren die Provider-Status weiter, bis ein Endstatus erreicht ist.
5. Fehlerhafte oder von Binect stornierte Sendungen wechseln in Manuelle Prüfung. Der zugehörige Dokument- oder E-Mail-Prozess erhält print_failed und wird nach erfolgreichem Retry oder manueller Klärung über print_resolved fortgesetzt.

Liste und Filter

Die Tabelle zeigt die wichtigsten Kontrollinformationen pro Sendung.

Filter stehen für Dienstleister, Umgebung, Provider-Status, Verarbeitung, Quelle, Sendungsart, Webhook-ID, RenderProcess-ID und EmailProcess-ID bereit.

Sendungsart und Spaltenauswahl

Über Sendungsart lässt sich die Liste auf Normalbrief, Einschreiben, Einwurf-Einschreiben, Internationales Einschreiben, Premiumadress Basis oder Premiumadress Report eingrenzen. Der Filter wirkt auf die gesamte Treffermenge und kann mit den übrigen Filtern kombiniert werden.

Unter Spalten konfigurieren können Sie Sendungsnummer und Sendungsart einblenden sowie die Reihenfolge der Spalten ändern. Für mich anwenden speichert die Auswahl für Ihren Benutzer; über Als Standard speichern lässt sie sich als Mandantenstandard übernehmen. Die Aktionsspalte bleibt immer sichtbar.

Die Sendungsart wird an der Drucksendung gespeichert und bleibt beim Archivieren der Rohantworten erhalten. Bestehende Binect-Sendungen werden anhand der gespeicherten Providerantwort oder ihrer versionierten Webhook-Konfiguration ergänzt. Lässt sich die damalige Sendungsart nicht verlässlich bestimmen, bleibt sie leer und wird bei einem konkreten Sendungsartfilter nicht angezeigt. Für E-POSTBUSINESS wird keine Binect-Sendungsart angenommen.

Aktionen

• Aktualisieren lädt die Liste neu.
• Status synchronisieren fragt offene Binect- und E-POSTBUSINESS-Sendungen sofort ab.
• Details zeigt Status, Provider-ID, Upload-Versuche, nächste Synchronisierung, Fehler, Kosten und Rohantworten.
• Upload erneut versuchen ist möglich, solange der Provider noch keine Dokument-ID geliefert hat und die Sendung in retry_wait oder manual_review steht.
• Manuell erledigen schließt eine Sendung aus manual_review, wenn der Fall außerhalb von Output.Rocks geklärt wurde.
• RP und EP springen direkt zum zugehörigen Dokument- oder E-Mail-Prozess.

Statusmodell

Provider-Status beschreiben den fachlichen Stand beim Druckdienstleister:

Die interne Verarbeitung steuert Upload, Retry und manuelle Prüfung:

Fehler, Retry und Rohdaten

Provider-Meldungen werden als Fehler oder Warnungen gesammelt und in der Liste über ein Warnsymbol angezeigt. Die Details enthalten zusätzlich den aktuellen Fehlertext und die Rohantworten der Upload- und Statusabfragen.

Bei temporären Fehlern plant Output.Rocks automatische Upload-Retries mit Backoff ein: 60 Sekunden, 5 Minuten, 15 Minuten, 1 Stunde und danach 2 Stunden. Nach mehreren erfolglosen Versuchen oder bei Authentifizierungsfehlern wechselt die Sendung in Manuelle Prüfung.

Der reguläre Workflow-Retrigger nimmt außerdem hängen gebliebene Sendungen in pending_submission und retry_wait wieder auf.

Rohantworten werden vor der Speicherung bereinigt. Sensible Adress-, Empfänger-, Absender- und E-Mail-Felder werden maskiert. Nicht privilegierte Benutzer sehen in den Details nur, dass Rohdaten zurückgehalten wurden; Admins und Super-Admins können die bereinigten Rohantworten einsehen.

Betrieb

Der reguläre Betrieb erfolgt über geplante Aktionen:

Offene Sendungen werden nach erfolgreichen Uploads typischerweise alle fünf Minuten erneut synchronisiert, bis ein Endstatus erreicht ist.

Sendungsnummern für Binect-Einschreiben

Für Binect-Einschreiben (REGMAIL_*) speichert Output.Rocks Sendungsnummer und Trackinglink dauerhaft an der Drucksendung. Beide stehen in der Detailansicht, auch nach dem Versandabschluss. Versendet ist keine Zustellbestätigung. Das Zustellergebnis wird durch diesen Ablauf nicht ausgewertet.

Der Trackinglink wird von Binect mitgeliefert. Für die Sendungsverfolgungsseite der Deutschen Post korrigiert Output.Rocks den von Binect gelieferten URL-Parameter trackingId auf piececode. Das gilt auch für bereits gespeicherte Links in der Detailansicht und in der API; dafür ist weder ein erneuter Trackingabruf noch ein erneuter Briefversand erforderlich. Die API-Feldnamen trackingId und trackingUrl bleiben gleich.

Die Nummer kann erst später bei Binect verfügbar sein. Die vorhandene geplante Aktion sync-binect-print-deliveries fragt sie deshalb auch bei bereits versendeten Einschreiben weiter ab: höchstens 28 automatische Versuche im Abstand von sechs Stunden, bei einer längeren Provider-Wartefrist entsprechend später. Der erste Versuch erfolgt beim nächsten Synchronisierungslauf nach dem Versand. Normale Briefe erhalten keine zusätzliche Trackingabfrage.

Die Detailansicht zeigt Trackingstatus, letzte und früheste nächste Abfrage sowie Hinweise bei fehlenden Daten oder Providerfehlern. Nach ausgeschöpften Versuchen steht dort Automatische Versuche beendet. Berechtigte Personen können Sendungsnummer nachladen auslösen, auch für ältere abgeschlossene Einschreiben. Wiederholungen innerhalb von fünf Minuten werden zusammengefasst; eine bereits vorgemerkte nächste Abfrage wird auch beim manuellen Nachladen respektiert. Dabei wird nur GET /regmails/{documentID} bei Binect gelesen. Es entstehen weder ein neuer Brief noch eine neue Rendering- oder Webhook-Kette. Bestehende Nummern bleiben bei einem fehlgeschlagenen erneuten Abruf erhalten.

Automatisierte Abfrage mit API-Token

Der reguläre OR-API-Token wird im Header X-AUTH-TOKEN übertragen:

curl --fail --get 'https://app.output.rocks/api/print-deliveries/tracking' \
  --header "X-AUTH-TOKEN: $OR_API_TOKEN" \
  --data-urlencode 'limit=100'

Auf Staging ist dieselbe Route unter https://app.staging.output.rocks erreichbar. Die Abfrage liest ausschließlich gespeicherte Daten und ruft Binect nicht auf.

{
  "items": [{
    "id": 25923,
    "providerDocumentId": "48495439",
    "trackingId": "RQ791878015DE",
    "trackingUrl": "https://www.deutschepost.de/de/s/sendungsverfolgung.html?piececode=RQ791878015DE",
    "trackingStatus": "available",
    "trackingAttemptCount": 2,
    "trackingLastSyncedAt": "2026-10-29T10:00:00+01:00",
    "trackingNextSyncAt": null,
    "trackingError": null,
    "dispatchStatus": "sent",
    "renderProcessId": 26824682,
    "emailProcessId": null,
    "renderingRequestId": 123,
    "externalReference": "vertrag-beispiel",
    "subClientId": null,
    "updatedAt": "2026-10-29T10:00:00+01:00"
  }],
  "nextAfterId": null
}

Die Werte sind ein illustratives Beispiel. externalReference verwendet die externe ID des Dokumentprozesses, ersatzweise die externe ID des ursprünglichen Rendering-Auftrags. Für eine Vertragszuordnung muss der Aufrufer diese Referenz bereits beim ursprünglichen Rendering mitgeben. Es werden keine Vertragsdaten aus Rohantworten abgeleitet. Nach Löschung des zugehörigen Prozesses können dessen Zuordnungsfelder leer sein.

• limit: positive ganze Zahl, Standard 100, maximal 500.
• afterId: letzte ID der vorherigen Seite; Reihenfolge aufsteigend nach Drucksendungs-ID. Solange nextAfterId eine Zahl enthält, diese als afterId für die nächste Seite übergeben.
• Jeden täglichen Lauf wieder ohne afterId beginnen. Ältere Sendungen können ihre Nummer später erhalten. Eine dauerhaft gespeicherte letzte ID würde diese Änderungen übersehen. Im Folgeprozess anhand der stabilen Drucksendungs-ID abgleichen.
• trackingStatus: pending, available oder exhausted. Fehlende Werte bleiben null; Providerprobleme stehen in trackingError, unabhängig vom Versandstatus.
• Ein Hauptmandanten-Token sieht Einschreiben seines Mandanten, ein SubClient-Token ausschließlich die eigenen. Andere Mandanten bleiben ausgeschlossen. Zugangsdaten und technische Rohantworten werden nicht ausgegeben.

Die tägliche Post-Statusabfrage und eine anschließende Vertragsanmerkung erfolgen im angebundenen Kundensystem.