Webhooks

Webhooks verbinden Output.Rocks mit externen Plattformen wie Powercloud, n8n, Binect, E-POSTBUSINESS oder kundeneigenen REST-Endpunkten. Sie werden genutzt, um Dokumente oder E-Mails für Folgeaktionen und Callbacks direkt zu übertragen, Statusänderungen zu empfangen oder Prozesse anzustoßen.

Die Übersicht der Datenkontexte zeigt, welche Platzhalter und Bedingungen in welcher Phase zur Verfügung stehen.

Einen Überblick dazu finden Sie auch im Use-Case E-Mail & Anhänge.

Webhook-Liste

Die Tabelle zeigt alle eingerichteten Webhooks inklusive Identifier, Typ und Mandantenkontext. Im Backend lassen sich über 30 vordefinierte Webhook-Typen auswählen, unter anderem SFTP-Uploads, Powercloud-spezifische Schnittstellen oder generische Custom-Endpoints.

ID, Identifier, Gruppen-Identifier, Aktiv ab, Aktiv, Typ

Mandant, Standard für Umgebungs-Mandanten

Erstellt am, Aktualisiert am

Ablaufübersicht

Die Schaltfläche Ablaufübersicht zeigt alle Treffer der aktuell gesetzten Such-, Gruppen-, Typ-, E-Mail- und Statusfilter – unabhängig von der Tabellenpaginierung. Die Übersicht gruppiert Webhooks nach Gruppen-Identifier beziehungsweise Identifier und trennt Rendering-Request-, Dokument- und E-Mail-Schritte sowie Pre-Rendering und anschließende Ausführung.

Innerhalb einer Phase entspricht die Reihenfolge der tatsächlichen Ausführung: zuerst nach Priorität (1 = zuerst), danach nach Webhook-ID. Die Knoten zeigen Typ, Status, Gruppenbedingung und bei E-Mail-Webhooks den Zustelltrigger. Ein Klick öffnet die bestehende Detailansicht. Die Ablaufübersicht ist schreibgeschützt; Änderungen erfolgen weiterhin über die Webhook-Liste.

Webhook erstellen

Die Schaltfläche Webhook erstellen öffnet geführte Einstiegskarten für die häufigsten Integrationen. SFTP, SharePoint und DropBox führen durch Upload-Ziel, Upload-Format und Details. Binect und E-POSTBUSINESS konfigurieren den physischen Druckversand. Powercloud öffnet einen eigenen Dialog, in dem zuerst der Anwendungsfall, danach bei Bedarf der Subtyp und anschließend Dokument oder E-Mail gewählt wird.

Powercloud-Erstellung

Der Powercloud-Dialog bildet die produktiv nutzbaren Powercloud-Typen ab:

Powercloud Custom API kann synchrone Antworten wie die übrigen Custom-Webhooks speichern. Bei E-Mail-Formaten mit Anhängen wird die Hauptantwort unter or.<responseDataKey>.email und jede Anhang-Antwort zusätzlich unter or.<responseDataKey>.attachments.<templateIdentifier> abgelegt. Punkte, spitze Klammern und Leerzeichen im Template-Identifier werden dabei durch _ ersetzt; gleiche Identifier erhalten in Ausführungsreihenfolge die Suffixe _2, _3 usw. Für diesen Fan-out ist responseDataRoot: "renderData" nicht zulässig. Reine EML-, HTML- und PDF-Uploads verwenden dagegen die normale Antwort-Speicherung.

ZUGFeRD-Mapping für Dokumente und E-Mail-Anhänge

Die ZUGFeRD-Mapping-Webhooks für Powercloud (prerender-powercloud-zugferd-mapping-document) und kVASy (prerender-kvasy-zugferd-mapping-document) werden weiterhin als Dokument-Webhooks konfiguriert. Dieselbe Konfiguration greift automatisch auch für PDF-Dokumente, die aus einer Dokumentvorlage als Anhang eines E-Mail-Prozesses gerendert werden.

Der Webhook wird dabei dem Dokumentprozess des Anhangs zugeordnet und vor dessen Rendering ausgeführt. Er läuft nicht auf dem übergeordneten E-Mail-Prozess. Deshalb zeigt die Webhook-Liste für diese Typen in der Spalte Für E-Mails weiterhin Nein an.

Identifier, Gruppen-Identifier und Gruppenbedingungen werden wie bei normalen Dokumentprozessen ausgewertet. Bei einer Gruppenbedingung steht das jeweilige Attachment-Template als Prozesskontext zur Verfügung.

Zusätzliche Rechnungshinweise über or.eInvoiceNotes

Neben den Hinweisen, die der Konvertierungsdienst selbst aus den Rechnungsdaten erzeugt, können Sie eigene Hinweistexte (EN 16931 BG-1, BT-22 Inhalt und BT-21 Betreffcode) mitgeben. Hinterlegen Sie sie unter dem reservierten Schlüssel or.eInvoiceNotes — entweder direkt im Payload oder über ein Custom Mapping.

{
  "or": {
    "eInvoiceNotes": [
      { "content": "Zahlbar ohne Abzug innerhalb von 14 Tagen." },
      { "content": "Steuerschuldnerschaft des Leistungsempfängers.", "subjectCode": "AAI" }
    ]
  }
}

Der Wert gilt für beide E-Rechnungs-Wege: die ZUGFeRD-Mapping-Webhooks und die eigenständige XRechnung-Erzeugung über XML-Prozesse. Die Hinweise werden hinter den Hinweisen des Konverters angehängt, in der angegebenen Reihenfolge.

Druckdienstleister-Webhooks

Binect und E-POSTBUSINESS sind Webhook-Typen für physischen Briefversand. Sie erzeugen nach dem Rendering eigene Drucksendungen, die unter Druckversand überwacht werden.

API-Webhook-Typen

Für kundeneigene APIs, Demo-Endpunkte und Automationsplattformen gibt es Webhook-Typen für zwei unterschiedliche Stellen im Rendering-Ablauf: Pre-Rendering und After-Rendering.

Metadaten in Custom-Webhooks

Die Typen custom-document, custom-email, custom-oauth2-document und custom-oauth2-email sowie ihre Pre-Rendering-Varianten können in URL, Headern und options.json auf Metadaten des Rendering Requests zugreifen. <<metadata.quelle>> liest einen einzelnen Wert; <<metadata>> übergibt das ganze Metadatenobjekt. Der bisherige Pfad <<or.metadata.quelle>> bleibt für bestehende Konfigurationen verwendbar. Andere Werte unter or werden dabei nicht überschrieben. Die übrigen Renderdaten liegen bei Custom-Webhooks direkt an der Wurzel des Platzhalterkontexts: Für Renderdaten { "kunde": { "nummer": "C-42" } } gilt <<kunde.nummer>>.

{
  "method": "POST",
  "url": "https://example.org/callback",
  "options": {
    "headers": { "Content-Type": "application/json" },
    "json": {
      "quelle": "<<metadata.quelle>>",
      "requestMetadata": "<<metadata>>",
      "kundennummer": "<<kunde.nummer>>"
    }
  }
}

Steht <<metadata>> allein als JSON-Wert, bleibt das Ergebnis ein JSON-Objekt. Welche Daten in anderen Phasen verfügbar sind, zeigt die Kontextübersicht.

Callbacks für ungültige und blockierte Prozesse

Je vier Custom- und Custom-OAuth2-Typen führen einen Callback aus, wenn ein Dokument- oder E-Mail-Prozess fehlschlägt:

Die Typwahl bestimmt den Auslöser. Die HTTP-Konfiguration folgt dem jeweiligen Custom- beziehungsweise Custom-OAuth2-Webhook mit method, url und options; bei OAuth2 wird wie üblich zuerst ein Access Token angefordert. Ein Powercloud-spezifischer contract- oder order-Wert ist dafür nicht erforderlich. In URL, Headern und JSON-Payload steht zusätzlich error zur Verfügung:

{
  "status": "<<error.status>>",
  "phase": "<<error.phase>>",
  "message": "<<error.message>>",
  "requestId": "<<error.requestId>>",
  "processId": "<<error.processId>>",
  "failedValidators": "<<error.failedValidators>>",
  "metadata": "<<metadata>>"
}

status ist invalid oder blocked; phase benennt request, render oder email. failedValidators enthält die Fehlermeldungen fehlgeschlagener Validatoren und ist sonst leer. Bei einem Fehler schon in der Request-Zuordnung ist processId null. Ein Fehler-Callback kann vor der Dateierzeugung stattfinden: Verwenden Sie hier keine Pflicht-Platzhalter wie <<document.base64File>> oder <<email.eml.base64File>>. Scheitert der Callback selbst, bleibt der ursprüngliche Prozessstatus erhalten. Die Datenvalidierung greift nur, wenn das Modul Datenvalidierung beim Mandanten aktiv und der Vorlage ein Validator zugeordnet ist.

Antwort-Speicherung und Webhook-Verkettung

Synchrone Custom-Webhooks können ihre JSON-Antwort im gemeinsamen RenderData-Bus speichern. Das wird für custom-document, custom-email, custom-oauth2-document, custom-oauth2-email, die drei prerender-custom-oauth2-*-Typen sowie powercloud-custom-ouauth2-document und powercloud-custom-ouauth2-email unterstützt. Asynchrone Versandprovider wie Binect und E-POSTBUSINESS sind ausgenommen, weil ihre spätere Provider-Antwort nicht in derselben Webhook-Kette vorliegt.

Die Konfigurationsfelder haben folgende Bedeutung:

• responseDataKey: aktiviert die Speicherung und benennt das Ziel. Für die drei prerender-custom-oauth2-*-Typen ist der Schlüssel erforderlich, sofern mergeResponse nicht aktiviert ist; bei den übrigen Typen bedeutet ein fehlender oder leerer Schlüssel: keine Speicherung.
• responseDataRoot: or (Standard) speichert unter or.<responseDataKey>; renderData schreibt direkt in die Renderdaten.
• mergeResponse: merged eine JSON-Objekt-Antwort rekursiv in vorhandene Daten. Ohne Schlüssel kann damit in die gewählte Wurzel gemerged werden. JSON-Listen und Skalare sind beim Merge nicht zulässig.
• responseValuePath: wählt vor dem Speichern per Punktpfad einen Teil der Antwort, z.B. data.token. Ein fehlender Pfad stoppt den Webhook mit einer verständlichen Fehlermeldung.

Eine einzelne Antwort hat beispielsweise diese Form:

{
  "or": {
    "customerLookup": {
      "customerId": "4711",
      "status": "active"
    }
  }
}

Bei Powercloud Custom E-Mail-Formaten mit Anhängen bleiben Hauptantwort und Geschwister erhalten:

{
  "or": {
    "delivery": {
      "email": {
        "requestId": "main-123"
      },
      "attachments": {
        "invoice_final": { "requestId": "att-1" },
        "invoice_final_2": { "requestId": "att-2" }
      }
    }
  }
}

Folgewebhooks lesen gespeicherte Werte weiterhin mit Platzhaltern wie <<or.customerLookup.customerId>>. Webhooks laufen zuerst nach Priorität (1 ist am höchsten) und bei gleicher Priorität stabil nach ihrer ID. Damit kann ein früher Webhook etwa ein Token speichern und ein späterer Webhook dieses in URL, Header oder Body einsetzen:

{
  "method": "GET",
  "url": "https://api.example.test/customers/<<or.lookup.customerId>>"
}

Die Kette ist synchron: Ein Fehler beim HTTP-Aufruf, beim Pfad oder beim Auflösen eines Platzhalters stoppt den Workflow und nennt den fehlgeschlagenen Platzhalter im Workflow-Log. Ein Workflow-Retry führt den Webhook erneut aus; externe Endpunkte sollten deshalb idempotent sein. Antworten über 256 KB werden vollständig gespeichert, erzeugen aber eine Warnung im Log.

Demo API als Pre-Render-Datenquelle

Für die Demo API verwenden Sie bei OAuth2-Webhooks den Client-Credentials-Flow:

Access Token URL: https://demo.example/api/demo/oauth/token
Client ID:        or-demo-enloc
Client Secret:    or-demo-213-enloc
Additional Token Parameters: {}

Eine typische Pre-Rendering-Konfiguration für prerender-custom-oauth2-document oder prerender-custom-oauth2-email ruft den Payload einer hochgeladenen Beispiel-Datei ab:

{
  "method": "GET",
  "url": "https://demo.example/api/demo/files/<file-id>/payload",
  "responseDataRoot": "or",
  "responseDataKey": "example",
  "options": {
    "headers": {
      "Accept": "application/json"
    }
  }
}

Die Antwort steht danach im Rendering unter or.example. Wenn die Antwort direkt in die Rendering-Daten übernommen werden soll, kann responseDataRoot auf renderData gesetzt werden. Mit mergeResponse: true wird eine JSON-Objekt-Antwort in den Zielbereich gemerged; mit responseValuePath kann vorher ein Teil der API-Antwort ausgewählt werden.

Demo API als After-Rendering-Ziel

Für custom-oauth2-document kann ein gerendertes Dokument an die Demo API übergeben werden:

{
  "method": "POST",
  "url": "https://demo.example/api/demo/rendered-documents",
  "responseDataKey": "",
  "options": {
    "headers": {
      "Content-Type": "application/json",
      "Accept": "application/json"
    },
    "json": {
      "fileName": "<<document.filename>>",
      "base64File": "<<document.base64File>>",
      "description": "<<document.description>>",
      "customId": "<<document.customId>>"
    }
  }
}

Für custom-oauth2-email stehen entsprechend <<email.eml.base64File>>, <<email.html.base64File>>, <<email.sender>>, <<email.recipient>>, <<email.subject>> und <<email.attachments>> zur Verfügung. Die Demo API nimmt die Datei entgegen und zeigt sie anschließend in der Demo-Oberfläche bei Rendered Documents an.

Ticketsystem zuerst, Versand danach

Soll ein Ticketsystem die Vorgangsnummer in den Betreff setzen, muss das Ticket vor dem Rendern existieren. Dafür gibt es prerender-custom-request: Der Typ läuft einmal je Rendering-Request, bevor Vorlagen und E-Mails aufgelöst werden, und authentifiziert sich über gewöhnliche Header statt über OAuth2 - passend für APIs hinter einem festen Token.

Die Antwort landet über responseDataKey in den Renderdaten und steht damit in Gruppenbedingungen, im Betreff, in der Empfängerauflösung und in allen folgenden Prozessen zur Verfügung:

{
  "method": "POST",
  "url": "https://ticket.example.com/api/v1/tickets",
  "responseDataKey": "ticket",
  "options": {
    "headers": {
      "Authorization": "Token token=<<credentials.ticket_token>>",
      "Content-Type": "application/json"
    },
    "json": { "title": "<<data.subject>>" }
  }
}

Im Betreff der E-Mail-Vorlage steht danach etwa Ihre Anfrage [Ticket#<<or.ticket.number>>]. Output.Rocks rendert und versendet die Mail anschließend selbst, sodass Layout, Bilder und Schriften erhalten bleiben - anders als beim Umweg über einen Artikel im Ticketsystem, dessen HTML-Bereinigung externe Bilder und Schriftangaben in der Regel entfernt.

Neben dem base64-codierten HTML steht mit <<email.html.content>> auch das rohe HTML des gerenderten E-Mail-Bodys bereit. Das brauchen Zielsysteme, die die E-Mail selbst versenden und dafür das Markup erwarten statt einer Datei - etwa ein Ticketsystem, das daraus einen ausgehenden Artikel anlegt. Soll Output.Rocks in einem solchen Fall nicht selbst versenden, wird im Request einfach kein emailServer mitgegeben: Die E-Mail wird gerendert, das EML erzeugt, der Versand übersprungen und die Webhooks laufen wie gewohnt.

Archiv (WORM)

Befristeter Rechnungsdownload mit QR-Anschreiben

Beim Dokument-Archiv-Webhook s3-archive-document kann QR-Download-Anschreiben senden aktiviert werden. Die Funktion ist zunächst ausgeschaltet und gilt nur für PDF-Dokumente. Wählen Sie eine bestehende Dokumentvorlage für das Anschreiben und einen aktiven Binect-Dokument-Webhook desselben Mandanten bzw. Umgebungs-Mandanten. In Test und Staging muss dieser Binect-Webhook die Testumgebung verwenden. Die Linkdauer ist eine ganze Zahl von 1 bis 365 Tagen (Standard: 30). Die Archiv-Aufbewahrung bleibt davon unabhängig.

Die Anschreibenvorlage erhält source mit den wirksamen Quelldaten sowie archiveDownload.url, archiveDownload.expiresAt, archiveDownload.validityDays und archiveDownload.fileName. Bei aktiviertem Zugangscode enthält archiveDownload.accessCode den einmalig für dieses Anschreiben erzeugten Code; nehmen Sie ihn nur auf, wenn er dem Empfänger tatsächlich zugestellt werden soll. Eigene Vorlagen können eine QR-Code-Konfiguration mit Text <<archiveDownload.shortUrl>> verwenden. Die beigelegte A4-Standardvorlage erzeugt den QR-Code dagegen direkt über ihre Textmarke qrcode_archiveDownloadQr; ihre separate QR-Code-Konfigurationsliste bleibt leer. Optional kann die Vorlage <<archiveDownload.expiresAt>> als lesbaren Hinweis anzeigen. Das Anschreiben erhält eine eigene technische externalId; die Rechnungsreferenz steht unter source.externalId. Binden Sie keinen Rechnungs-Webhook, keine Rechnungsanlage und keine ZUGFeRD-Mapping-Regel an die Anschreibenvorlage.

Der Brief startet erst nach bestätigter Archivierung. Die Frist beginnt genau zu diesem Zeitpunkt und läuft in UTC nach jeweils 24 Stunden ab; Warteschlangen, Rendering und Postlaufzeit verlängern sie nicht. Der QR-Link liefert ohne Anmeldung ausschließlich die unveränderte archivierte PDF. In der Archivdetailansicht sehen berechtigte Personen Ablauf, Folgeauftrag und Fehler; Archivschutz-Berechtigte können den Link widerrufen. Der Widerruf stoppt neue Downloads und eine noch nicht begonnene Binect-Übergabe. Ein fehlgeschlagenes Anschreiben ändert den erfolgreichen Archivstatus nicht. Nach Korrektur von Vorlage oder Versandkonfiguration wird derselbe Folgeauftrag über die bestehenden Workflow-Wiederholungen fortgesetzt; es entsteht kein neuer Link.

Für den Betrieb muss ARCHIVE_DOWNLOAD_BASE_URL auf die vertrauenswürdige HTTPS-App-Domain der Umgebung gesetzt sein und /archive/download/ zum Backend führen. Der Wiederanlauf scannt jede Minute bestätigte, noch offene Fortsetzungen (archive-download-followups) und schickt sie über die vorhandene EntityAction-Verarbeitung erneut an. Prüfen Sie bei Fehlern den Folgeauftrag und den Freigabestatus; Token und Klartextlink dürfen nicht in Support-Logs übernommen werden.

Die Webhook-Typen s3-archive-document und s3-archive-email legen gerenderte Dokumente, E-Mails oder E-Mail-Anhänge im revisionssicheren Archiv ab. Im Konfigurations-Tab werden neben der Aufbewahrungsklasse und dem optionalen Löschzeitpunkt-Offset auch die Archiv-Metadaten gepflegt.

Für PDF-Dokumente kann zusätzlich PDF/A-3b-Fassung erzeugen aktiviert werden. Das Archiv prüft nach der Virenfreigabe zunächst mit veraPDF, ob das unveränderte Original bereits PDF/A-konform ist. Nur bei einem nicht konformen PDF wird eine eigene PDF/A-3b-Komponente erzeugt und erneut geprüft. Das Original bleibt maßgeblich und kann wie bisher heruntergeladen werden. Der Prüfstatus, das erkannte Profil und etwaige Fehler erscheinen im Archiveintrag. Bei technischen Fehlern bleibt das Original verfügbar; die Prüfung oder Umwandlung kann erneut angestoßen werden. Eingebettete Rechnungs-XML wird bytegleich in die zusätzliche Fassung übernommen.

Bei E-Mail-Archiv-Webhooks kann der HTML-Inhalt zusätzlich als PDF archiviert werden. Wird für eine E-Mail-Quelle originalFormat = pdf verwendet, konvertiert Output.Rocks den gerenderten E-Mail-Body nach PDF und speichert ihn mit application/pdf.

Das Feld Archiv-Metadaten akzeptiert ein JSON-Mapping oder einen einzelnen Platzhalter. Nur die dort konfigurierten Werte werden als Metadaten im Archiv gespeichert. Ein leeres Feld oder {} speichert keine Metadaten.

{
  "metadata": {
    "customerId": "<<data.customer.id>>",
    "invoiceNumber": "<<data.invoice.number>>",
    "documentType": "<<metadata.type>>",
    "fileName": "<<document.filename>>"
  }
}

Wenn die Archiv-Metadaten bereits vollständig in den Renderdaten vorbereitet sind, kann das Feld auch nur aus einem Platzhalter bestehen:

{
  "metadata": "<<data.archiveMetadata>>"
}

Der Platzhalter muss auf ein JSON-Objekt auflösen. Listen, einzelne Textwerte oder Zahlen werden nicht als Archiv-Metadaten akzeptiert.

Für E-Mail-Archiv-Webhooks kann das Mapping zusätzlich E-Mail-Kontext verwenden:

{
  "metadata": {
    "customerId": "<<data.customer.id>>",
    "emailSubject": "<<email.subject>>",
    "messageId": "<<email.messageId>>"
  }
}

Verfügbare Platzhalterquellen:

• data: zusammengeführte Renderdaten des Prozesses.
• metadata: Metadaten des aktuellen Dokument- oder E-Mail-Prozesses.
• document: Kontext des gerenderten Dokuments oder E-Mail-Anhangs, z.B. Dateiname, External ID, Custom ID, Rendering-Request-ID und Mandant.
• email: Kontext des E-Mail-Prozesses; bei Anhängen ist das der übergeordnete E-Mail-Prozess.

Archivierte Dokumente können über die M2M-API nach diesen Metadaten gefiltert werden. Der API-Token muss zum Mandanten gehören und das Archiv-Modul muss aktiviert sein:

curl -H "X-AUTH-TOKEN: <api-token>" \
  "https://<backend>/api/archive?metadata[customerId]=C-100&metadata[invoiceNumber]=INV-123"

Die Filterwerte werden exakt verglichen. Mehrere metadata[...]-Parameter werden kombiniert, sodass alle angegebenen Werte passen müssen. Die Datei selbst wird anschließend über den link aus dem Ingest-Response oder per Download-Endpunkt abgerufen:

curl -L -H "X-AUTH-TOKEN: <api-token>" \
  "https://<backend>/api/archive/<id>/download" \
  -o dokument.pdf

Formularstruktur

Details-Tab

Dieser Tab ist bei allen Webhook-Typen identisch und definiert Identifier, Priorität und Aktivierungslogik.

Mandant & Standard für Umgebungs-Mandanten

Ist das Modul für Umgebungs-Mandanten aktiv, legen Sie im Details-Tab fest, für wen ein Webhook gilt: für einen bestimmten Umgebungs-Mandanten oder – als Standard für Umgebungs-Mandanten – für den Hauptmandanten und alle Umgebungs-Mandanten gemeinsam.

Konfigurations-Tab

Zustellstatus-Trigger für E-Mail-Webhooks

Post-Render-E-Mail-Webhooks können nach dem Zustellstatus gefiltert werden. Im Webhook-Formular wählen Sie dafür Ausführung nach Zustellstatus:

• Immer: Webhook läuft bei zugestellten und gebouncten E-Mails.
• Nur bei Zustellung: Webhook läuft nur, wenn der Mailserver delivered meldet.
• Nur bei Bounce: Webhook läuft nur, wenn der Mailserver bounced meldet.

Die Einstellung ist für generische E-Mail-Uploads, Custom/OAuth2-E-Mail-Webhooks, SFTP, SharePoint, DropBox, Binect, E-POSTBUSINESS, S3-Archiv und die Powercloud-E-Mail-Upload-Typen verfügbar. Pre-Render-Webhooks und Request-Pre-Render-Webhooks bleiben davon ausgenommen.

E-Mail-Upload-Formate

Bei Webhooks mit E-Mail-Upload-Auswahl stehen diese Formate zur Verfügung:

• Vollständige E-Mail (.eml): lädt die komplette E-Mail inklusive MIME-Struktur hoch.
• Nur HTML-Inhalt: lädt den gerenderten E-Mail-Body als .html hoch.
• HTML-Inhalt als PDF: konvertiert den gerenderten E-Mail-Body nach PDF und lädt nur dieses PDF hoch.
• Nur Anhänge: lädt ausschließlich gerenderte und statische E-Mail-Anhänge hoch.
• HTML-Inhalt und Anhänge: lädt den rohen HTML-Body plus Anhänge hoch.
• HTML-Inhalt als PDF und Anhänge: lädt den E-Mail-Body als PDF plus alle Anhänge hoch.

Die PDF-Varianten gelten für SFTP, SharePoint, DropBox, S3-Archiv sowie Powercloud Archive/Custom OAuth2 E-Mail-Uploads. Bestehende Webhooks behalten ihr gespeichertes Format.

Für HTML-Inhalt als PDF und HTML-Inhalt als PDF und Anhänge wird derselbe konfigurierbare E-Mail-PDF-Header wie beim Download im E-Mail-Prozess verwendet. Maßgeblich ist die Einstellung des Mandanten beziehungsweise Umgebungs-Mandanten unter Mandanten-Einstellungen → E-Mail-PDF; dabei gilt die Vererbung Systemstandard → Mandant → Umgebungs-Mandant. Ist der Header dort deaktiviert, bleibt auch das Webhook-PDF ohne Header.

Testen und Löschen

Die Zeilenaktionen öffnen Anzeigen, Versionsverlauf und Ändern. Für Custom-, Custom-OAuth2- und ihre Pre-Rendering-Typen sowie die acht Fehler-Callbacks gibt es außerdem Webhook testen. Geteilte Webhooks eines Hauptmandanten bleiben für Nutzer eines Umgebungs-Mandanten schreibgeschützt; die Test- und Löschaktionen sind dort deaktiviert.

Im Testdialog bearbeiten Sie ein JSON-Objekt als rohen Platzhalterkontext. Die Schlüssel liegen an der Wurzel: Für <<kunde.nummer>> geben Sie { "kunde": { "nummer": "C-42" } } ein. Ein data-Schlüssel ist nur nötig, wenn Ihr Platzhalter tatsächlich mit <<data.*>> beginnt. Für Metadaten, Dokumente, E-Mails und Fehler können Sie metadata, document, email und error ergänzen. Vorschau löst die Platzhalter auf und zeigt Methode, URL und Optionen ohne Netzwerkaufruf. Testanfrage senden ruft das konfigurierte Ziel tatsächlich auf und zeigt HTTP-Status und gekürzte Antwort. Zugangsdaten werden in der Anzeige verdeckt. Der Test ändert keine gespeicherte Webhook-Konfiguration und erzeugt keinen Rendering-Prozess; die Beispiele müssen die Platzhalter Ihrer Konfiguration abdecken.

Löschen öffnet eine Bestätigung. Ein Webhook, auf den Prozesse, Zustellungen oder deren Historie noch verweisen, kann nicht gelöscht werden; deaktivieren Sie ihn in diesem Fall. Nur ein ungenutzter Webhook lässt sich entfernen. Ein Testversand kann beim externen Ziel eine Aktion auslösen, daher vor dem Senden Ziel und Payload in der Vorschau prüfen.

Filter

• Filtern öffnet das Modal mit Suchkriterien wie Identifier, Typ oder Mandant.
• Zurücksetzen setzt alle Kriterien zurück und schließt das Modal.
• Anwenden übernimmt die Auswahl, aktualisiert die Tabelle sofort und schließt den Dialog.

Spalten konfigurieren

Das Konfigurationsmodal bietet drei Speicherpfade:

• Für mich anwenden – persönliche Ansicht.
• Als Standard anwenden – gesamte Umgebung nutzt diese Sicht.
• Auf Standard zurücksetzen – ursprüngliche Spaltenauswahl reaktivieren.

Weitere Bedienelemente

• Pagination zeigt im Footer die Anzahl der Treffer (z.B. „2 Ergebnisse“). Bei mehr Seiten erscheinen Zurück/Weiter-Buttons.