Version, User & System Webhook Events Reference

This reference provides the full payload structure and a JSON example for every webhook event published for the Version entity, the User entity, product catalog uploads, and asynchronous request failures.

For the list of events and what triggers them, see Webhooks Overview.

📘

Optional Fields

Fields with no value in DealHub are omitted from the event payload entirely. This applies to every event described below.

Version (version)

Published on different activities around the Version entity — for example, when an administrator creates a new version, activates a version, or reactivates a version.

The created action fires both when a version is created from scratch and when it's created by duplicating an existing version.

{
  "event": "version",
  "action": "created",
  "status": "draft",
  "version_id": "786865656565",
  "version_name": "some name",
  "execution_date": "2021-10-22 16:39:08",
  "executed_by": "[email protected]",
  "impersonated_by": ""
}

The table below describes each field in the payload:

FieldDescriptionCan be omittedValid Values / Format
eventBusiness event typeNo"version"
actionAction performed on the versionNo"created", "activated", "reactivated"
statusVersion statusNo"draft", "active", "deactivated"
version_idID of the versionNo16 chars
version_nameName of the versionNo
execution_dateGMT date/time of the actionNoyyyy-mm-dd hh:mm:ss, e.g. 2021-10-22 09:34:44
executed_byLogin of the administrator who performed the actionNo
impersonated_byLogin of the admin, if they performed the action on behalf of another userYes

Products Upload (productsUpload)

Published once an SFTP product file upload or Open API upload completes. An SFTP upload loads data into every draft Version available for the account at upload time, so this event is published once per affected draft Version.

This event always carries a request_id in the event_info structure (see Webhooks Overview), letting the consuming system tell apart different asynchronous upload requests. For SFTP uploads, files dropped into the SFTP folder should use a naming convention like triggerImport_{TimeInMilliseconds}.txt so each upload attempt gets a unique identifier, which becomes the request_id.

The payload differs slightly depending on whether the upload succeeded or failed:

{
  "event": "productsUpload",
  "upload_status": "success",
  "version_id": "786865656565",
  "version_name": "some name",
  "imported_skus": "34"
}
{
  "event": "productsUpload",
  "upload_status": "error",
  "version_id": "786865656568",
  "version_name": "master_version_2503",
  "imported_skus": "29",
  "errors": "4"
}

The table below describes each field in the payload:

FieldDescriptionCan be omittedValid Values / Format
eventBusiness event typeNo"productsUpload"
upload_statusStatus of the products data uploadNo"success", "error"
version_idID of the versionNo16 chars
version_nameName of the versionNo
imported_skusNumber of lines (SKUs) loaded into the versionNo
errorsNumber of lines (SKUs) that could not be loaded into the version. Zero on success.No

User (user)

Published when an action is performed on the User entity. User types include sales reps, administrators, DealRoom users (selling-org users invited to a DealRoom), and partner users.

The payload is the same shape for every action — only the values change:

{
  "event": "user",
  "action": "created",
  "user_external_id": "",
  "user_id": "786865656908",
  "user_login": "James_Parker",
  "execution_date": "2021-10-22 16:39:08",
  "executed_by": "SYSTEM"
}
{
  "event": "user",
  "action": "modified",
  "user_external_id": "kjnk43nk443",
  "user_id": "786865656565",
  "user_login": "James_Parker",
  "execution_date": "2021-10-22 16:39:08",
  "executed_by": "[email protected]"
}

The table below describes each field in the payload:

FieldDescriptionCan be omittedValid Values / Format
eventBusiness event typeNo"user"
actionAction performed on the userNo"created", "modified", "deleted"
user_external_idExternal (CRM) ID of the user, persisted when the user is created via authentication or another relevant API. Empty when the user is created by an internal DealHub process (e.g. an admin created the user via the UI, or a non-existing selling-org user was invited to a DealRoom).Yes
user_idDealHub user IDNo16 chars
user_loginLogin of the user in DealHubNo
execution_dateGMT date/time of the actionNoyyyy-mm-dd hh:mm:ss, e.g. 2021-10-22 09:34:44
executed_byLogin of the administrator, if they performed the action explicitly; otherwise "SYSTEM" (e.g. the system creates a new sales rep user upon first authentication)No"SYSTEM" or an administrator login
impersonated_byLogin of the admin, if they performed the action on behalf of another userYes

Failure WebHook v1

Published if the system fails to execute an asynchronous API request — for example, a request to duplicate or activate a version.

{
  "error_description": "",
  "error_code": ""
}

The table below describes each field in the payload:

FieldDescriptionCan be omittedValid Values / Format
error_descriptionDescription of the error when the request status is "failed"Yes
error_codeCode of the error when the request status is "failed"Yes

Did this page help you?