Webhooks

Ein Webhook ist eine automatische Benachrichtigung der DQC Platform an ein anderes System. Sobald eine Datenqualitätsprüfung (Ruleset-Lauf) oder eine Datenverbesserung (Improvement) abgeschlossen ist, sendet DQC eine Nachricht mit dem Ergebnis an eine von Ihnen festgelegte Adresse. Niemand muss manuell nachsehen oder auf eine E-Mail warten — der Folgeschritt kann sofort starten.

Typische Einsatzszenarien:

• Automatisch einen Folgeprozess in einem anderen System starten, sobald die Datenprüfung bestanden ist (z. B. Daten für eine Migration oder eine Schnittstelle freigeben).

• Das eigene Ticket- oder Workflow-System informieren, wenn eine Prüfung Probleme gefunden hat, damit das zuständige Team sofort reagieren kann.

• Verbesserte Daten nach Abschluss eines Improvements automatisch an ein nachgelagertes System übergeben.

Gut zu wissen: den Webhook richten Sie in DQC selbst mit wenigen Klicks ein. Die Empfängerseite (die Adresse, an die die Nachrichten gehen) stellt in der Regel Ihre IT-Abteilung oder der Anbieter des Zielsystems bereit.

Wo Sie Webhooks finden

Webhooks werden direkt an dem Objekt eingerichtet, dessen Abschluss die Benachrichtigung auslösen soll:

• Für ein Ruleset: öffnen Sie das Ruleset und klicken Sie oben auf das Webhook-Symbol. Dieser Webhook meldet jeden abgeschlossenen Prüf-Lauf dieses Rulesets.

• Für ein Data Improvement: öffnen Sie den Improvement-Workflow und klicken Sie oben auf das Webhook-Symbol. Dieser Webhook meldet jeden abgeschlossenen Improvement-Lauf.

Wer das Ruleset bzw. Improvement sehen darf, sieht auch dessen Webhooks. Zum Anlegen, Ändern, Testen oder Löschen benötigen Sie Bearbeitungsrechte auf dem Ruleset bzw. Improvement.

Einen Webhook Schritt für Schritt einrichten

1. Öffnen Sie das Ruleset oder Improvement und klicken Sie auf das Webhook-Symbol.

2. Klicken Sie auf Webhook anlegen und vergeben Sie einen Namen, den Sie später wiedererkennen (z. B. „SAP-Schnittstelle benachrichtigen“).

3. Tragen Sie die Ziel-Adresse (URL) des empfangenden Systems ein — diese erhalten Sie von Ihrer IT-Abteilung.

4. Wählen Sie, wie viele Daten die Nachricht enthalten soll (siehe unten „Welche Daten werden gesendet?“).

5. Speichern Sie. DQC zeigt jetzt einen Sicherheitsschlüssel (Signing Secret) an — nur ein einziges Mal. Geben Sie ihn an Ihre IT-Abteilung weiter: Damit kann das empfangende System sicherstellen, dass Nachrichten wirklich von DQC stammen. Geht der Schlüssel verloren, legen Sie einfach einen neuen Webhook an.

6. Klicken Sie auf Test, um sofort eine Testnachricht zu senden und zu sehen, ob das empfangende System antwortet.

Die Felder im Überblick:

Welche Daten werden gesendet?

Jede Nachricht enthält immer die Ergebnis-Zusammenfassung: welches Ruleset bzw. Improvement gelaufen ist, wann es abgeschlossen wurde und die Kennzahlen des Laufs (bei Prüfungen: Qualitätsbewertung, Anzahl gefundener Probleme, Anzahl geprüfter Zeilen und Spalten; bei Improvements: Name und Größe des verbesserten Datenbestands).

Zusätzlich können Sie wählen, ob auch echte Datenzeilen mitgesendet werden:

Tipp: senden Sie vollständige Daten nur mit, wenn das empfangende System sie wirklich benötigt. Für reine Benachrichtigungen („Prüfung fertig, Qualität B, 3 Probleme“) genügt die Zusammenfassung — und es verlassen keine Inhaltsdaten die Plattform.

Wie zuverlässig ist die Zustellung?

• Ist das empfangende System vorübergehend nicht erreichbar, versucht DQC es automatisch erneut — insgesamt bis zu dreimal (sofort, nach 30 Sekunden, nach 5 Minuten).

• Im Webhook-Dialog sehen Sie jederzeit die letzten 50 Zustellungen — inklusive der Information, ob sie erfolgreich waren und was das empfangende System geantwortet hat. Das ist die erste Anlaufstelle, wenn etwas nicht ankommt.

• Ein Webhook beeinträchtigt Ihre Prüfungen und Improvements nie: Sie laufen immer normal durch, auch wenn das empfangende System nicht erreichbar ist.

Technische Details für Ihre IT

Dieser Abschnitt richtet sich an das Team, das die Empfängerseite umsetzt.

DQC sendet einen HTTPS-POST-Request mit JSON-Body (schemaVersion 1.0). Beispiel für einen abgeschlossenen Ruleset-Lauf:

{
  "schemaVersion": "1.0",
  "eventType": "ruleset.run.completed",
  "id": "9f4c1e2a-…",
  "requestId": "3b8d0f6c-…",
  "triggeredAt": "2026-07-06T12:00:00+00:00",
  "customData": { "team": "mdm-core" },
  "meta": { "connectorId": "…", "tableId": "…", "rulesetId": "…" },
  "runInfo": {
    "id": "…",
    "rulesetName": "Material master checks",
    "qualityRatio": 0.98,
    "qualityScore": "A",
    "issues": 3,
    "rows": 1000,
    "columns": 12
  },
  "issuesSample": null,
  "completeIssueData": null
}

Bei Improvements enthält der Payload meta (connectorId, tableId, rulesetId, improvementId), improvementInfo (id, improvementName, rows, columns) und — falls aktiviert — data mit den verbesserten Zeilen.

Jeder Request enthält folgende Header: X-DQC-Signature, X-DQC-Request-Id (identisch über alle Wiederholungen — zur Deduplizierung nutzen), X-DQC-Event-Type, X-DQC-Timestamp und X-DQC-Delivery-Attempt. Die Signatur ist ein HMAC-SHA256 über "<timestamp>.<body>" mit dem bei der Erstellung einmalig angezeigten Signing Secret:

import hashlib, hmac

signature = headers["X-DQC-Signature"]          # "sha256=<hex>"
timestamp = headers["X-DQC-Timestamp"]
expected = "sha256=" + hmac.new(
    signing_secret.encode(),
    f"{timestamp}.".encode() + raw_body_bytes,
    hashlib.sha256,
).hexdigest()
valid = hmac.compare_digest(expected, signature)

• Antworten Sie innerhalb von 10 Sekunden mit einem 2xx-Status und verarbeiten Sie den Payload asynchron.

• Wiederholungen erfolgen bei Netzwerkfehlern, HTTP 429 und HTTP 5xx; andere 4xx-Antworten werden nicht wiederholt.

• Verifizieren Sie immer die Signatur, bevor Sie einem Request vertrauen, und nutzen Sie die requestId, um die Verarbeitung idempotent zu machen.