Webhooks in Supplier Data Manager (SDM) let you receive real-time HTTP notifications when specific events occur in your SDM workflow. Instead of polling the API to check job status, your systems receive an immediate push notification the moment a trigger event fires.

Supported triggers

Supplier Data Manager supports two webhook trigger types at the project level.

Job Done

The Job Done trigger fires when a job completes all steps and reaches the final "Download output" page.

Payload:

{
  "job_id": "<UUID of the job>",
  "last_editor": "<email of the last editor, or null if none>",
  "completion_date": "<ISO 8601 timestamp of when the job completed>"
}

Step Completed

The Step Completed trigger fires when an individual step within a job finishes.

Payload:

{
  "job_id": "550e8400-e29b-41d4-a716-446655440000",
  "step_id": "123e4567-e89b-12d3-a456-426614174000",
  "step_name": "Extraction",
  "step_type": "extraction",
  "step_number": 2,
  "completion_date": "2025-01-16T14:25:00Z"
}

Configure a webhook in Supplier Data Manager

To create or manage webhooks in Supplier Data Manager, you must have access to the SDM Admin Panel.

1. In the SDM Admin Panel, go to Connectors > Project webhooks.
2. Click an existing webhook to edit it, or click Add project webhook to create a new one.
3. Enter the Url of the endpoint that will receive the webhook payload.
4. Optionally, enter Headers to include in every request — for example, an authorization token: json { "token": "xxxxxxxxx" }
5. Select the Project this webhook applies to.
6. Select the Trigger — either Job done or Step completed.
7. Save the webhook.

The screenshot above shows the "Add project webhook" form in the SDM Admin Panel, with fields for URL, Headers (JSON), Project, and Trigger.

Webhook delivery

When a trigger event fires, Supplier Data Manager sends an HTTP POST request to the configured URL with Content-Type: application/json.

Delivery is asynchronous — the request is enqueued after the database transaction commits, so your endpoint will not be called before the triggering change is fully saved.

Retry behavior: If the initial request fails or the server returns an error status (429, 500, 502, 503, 504), SDM retries the request up to 3 times with exponential backoff.

Timeout: Each delivery attempt times out after 30 seconds. If your endpoint does not respond within 30 seconds, the attempt is abandoned and the retry sequence continues.

Limitations

• Dynamic IP addresses: Webhook requests are sent from a pool of dynamic IP addresses. The specific IP address sending the webhook to your server may change over time without prior notice. Do not use IP allowlists to secure webhooks — use a secret token in the Headers field instead.
• No delivery guarantees: Webhooks are best-effort. If all retry attempts fail, the event is not requeued. Design your systems to tolerate occasional missed notifications, for example by periodically reconciling state via the SDM API.
• One webhook per trigger per project: Each ProjectWebhook record is scoped to a single project and a single trigger type. To notify multiple endpoints, create a separate webhook record for each.