Product Change Webhooks 

  • Products are serialized using the product CRUD API JSON export format.  Click here for more information on format.
  • Products that have been destroyed will have salsify:destroyed_at property with the date of their delete.
  • parent_products array includes parent products for all products in the products section. The salsify:parent_id in product payload can be used to determine corresponding parent product.
  • trigger_type received will be add, change, or remove and correspond with the subscription types.

Setting Up a Webhook Notification

Inside the Salsify app, define the list of products and changes you want to receive notifications for. 

  • A product is added to this set - Notification is triggered when a new product is added to the specified list.
  • Any property is changed on a product in this set - Notification is triggered when any property is changed for the products in the specified list.
  • One of the properties I've selected is changed on a product in this set - Notification triggered when specified properties are updated for products in the list.
  • A product is removed from this set - This will trigger for products that are deleted as well as products that are changed to no longer fit the criteria. You can distinguish these in emails via the Destroyed column or in a webhook by checking whether 'salsify:destroyed_at' is set.

Click here for more information about setting up webhook notifications in Salsify.

Delivery Behavior

We will retry sending webhooks 15 times over a 48 hour period with an exponential backoff between attempts. Please note the following webhook behaviors:

  • Combined delivery for short time frames - Multiple updates to the same product in a short time period can be coalesced into a single webhook. For example, if the brand for a product is changed to WILDFLOWER and then quickly changed to Wildflower, you may only get a single webhook with the Wildflower version of the product.
  • Return to original state may not fire a webhook - A corollary of the above rule is that multiple updates to the same product that return the product back to its original state. For example, changing Brand from Wildflower to Dandelion, then quickly back to Wildflower, might not fire any webhooks.
  • Notifications are not sent upon list edit - When the filters are adjusted for a smart list and saved, and products are added or removed as a result, webhooks will not be triggered. They will trigger on subsequent changes to the products in the list.

Order of Delivery

  • Multiple updates of the same product - Multiple updates to the same product that are not coalesced will be delivered in order. For example, changing Brand to Wildflower, then Dandelion, then Leontodon will first fire a webhook with Brand = Dandelion (potentially retrying for up to 48 hours according to our retry policy) and then we’ll fire a webhook with Brand = Leontodon (again potentially retrying for up to 48 hours according to our retry policy).
  • Ordering of different products - There is no webhook delivery ordering guarantee for different products. For example,  you may get a webhook for a change to product ABC before product XYZ even if product XYZ was updated first.
  • Ordering of webhooks from different alerts - There are no webhook delivery ordering guarantees for webhooks generated by different alerts or other entities like imports and channels.

Example Webhook Payload

      "name":"Org Update"
      "name":"Supplier is Apple",
         "ProductName":"White iPhone6",
         "ProductName":"Black iPhone6",
         "Description":"One powerful phone.",