Webhooks

A webhook is an automatic notification from the DQC Platform to another system. As soon as a data quality check (ruleset run) or a data improvement has finished, DQC sends a message with the result to an address you define. Nobody has to check manually or wait for an email — the follow-up can start immediately.

Typical uses:

Automatically start a follow-up process in another system once the data check has passed (e.g., release data for a migration or an interface).
Inform your own ticket or workflow system when a check found issues, so the responsible team can act right away.
Automatically hand over improved data to a downstream system once an improvement has finished.

Good to know: you set up the webhook in DQC yourself in a few clicks. The receiving side (the address the messages are sent to) is usually provided by your IT department or the vendor of the target system.

Where to find webhooks

Webhooks are set up directly on the object whose completion should trigger the notification:

For a ruleset: open the ruleset and click the webhook icon at the top. This webhook reports every completed check run of this ruleset.
For a data improvement: open the improvement workflow and click the webhook icon at the top. This webhook reports every completed improvement run.

Anyone who can view the ruleset or improvement can also see its webhooks. To create, change, test, or delete webhooks you need edit rights on the ruleset or improvement.

Setting up a webhook step by step

Open the ruleset or improvement and click the webhook icon.
Click Create webhook and give it a name you will recognize later (e.g., "Notify SAP interface").
Enter the target address (URL) of the receiving system — you get this from your IT department.
Choose how much data the message should contain (see "What data is sent?" below).
Save. DQC now shows a security key (signing secret) — one time only. Pass it on to your IT department: it lets the receiving system confirm that messages really come from DQC. If the key is lost, simply create a new webhook.
Click Test to send a test message right away and see whether the receiving system responds.

The fields at a glance:

Field	What it means
Name	A label of your choice so you can recognize the webhook later.
URL	The address of the receiving system. You usually get it from your IT department. For security reasons it must be an encrypted address (https://…).
Custom headers	Only needed if the receiving system requires additional access information (e.g., an access key). Your IT will tell you whether this is necessary. These entries are stored encrypted.
Custom data	Optional extra information that is included in every message unchanged — for example a team or project name, so the receiving side knows how to route the message.
Data scope	Controls whether, in addition to the result summary, actual data rows are included (see below).
Active	Switch a webhook off temporarily without deleting it — for example during maintenance of the receiving system.

What data is sent?

Every message always contains the result summary: which ruleset or improvement ran, when it finished, and the key figures of the run (for checks: quality score, number of issues found, number of rows and columns checked; for improvements: name and size of the improved dataset).

On top of that, you can choose to include actual data rows:

Webhook on…	Optional data
Ruleset	Issue sample (up to 10 affected rows as examples) or complete issue data (all affected rows).
Improvement	Improved data (the rows as they look after the improvement).

Tip: only include full data if the receiving system really needs it. For pure notifications ("check finished, quality B, 3 issues") the summary is enough — and no content data leaves the platform.

How reliable is delivery?

If the receiving system is temporarily unavailable, DQC automatically tries again — up to three times in total (immediately, after 30 seconds, after 5 minutes).
In the webhook dialog you can see the last 50 deliveries at any time — including whether they succeeded and what the receiving system responded. This is the first place to look if something does not arrive.
A webhook never affects your checks and improvements: they always complete normally, even if the receiving system is unreachable.

Technical details for your IT

This section is aimed at the team implementing the receiving side.

DQC sends an HTTPS POST request with a JSON body (schemaVersion 1.0). Example for a completed ruleset run:

{
  "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
}

For improvements the payload contains meta (connectorId, tableId, rulesetId, improvementId), improvementInfo (id, improvementName, rows, columns) and — if enabled — data with the improved rows.

Every request carries these headers: X-DQC-Signature, X-DQC-Request-Id (identical across retries — use for deduplication), X-DQC-Event-Type, X-DQC-Timestamp and X-DQC-Delivery-Attempt. The signature is an HMAC-SHA256 over "<timestamp>.<body>" using the signing secret shown once at creation:

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)

Respond with a 2xx status within 10 seconds and process the payload asynchronously.
Retries happen on network errors, HTTP 429, and HTTP 5xx; other 4xx responses are not retried.
Always verify the signature before trusting a request, and use the requestId to make processing idempotent.