A webhook is a user-defined HTTP callback to a third-party application that is fired when some predetermined action occurs. Webhooks allow Platform admins to have a platform event, such as user creation, user addition onto a team, form creation, or submission submit, to reach out to another system and pass that system information. This is intended to be used to allow these events to trigger platform workflows, but they can be used for other integration purposes as well if necessary.

Data that corresponds to the action, such as a form being submitted, will be sent to the webhook URL as an HTTP Post action.

Each Action/Webhook within the Space, for example: user update, form create, submission submitted, has a specific path expected for the corresponding tree. These are not strictly required, but it is standard and expected use.

In the table below are a selection of common webhooks that are representative of the correspondence:

Webhook Jobs

Webhook jobs are instances of webhook events. These record the time of the event, the URL sent to, and the actual data sent.

This can be very helpful when trying to figure out what exactly was sent where out of the front end of the platform.

Workflow Runs

As you can see in the webhook job details above, the response content indicates a run number. This webhook is pointing at the workflow engine for the platform and triggered a run, or an instance of execution of built workflow. This is the most common use for platform webhooks.

A few important things to note:

• (Platform V5.0 and later ) Datastore Forms and Submissions have separate webhooks and tree groups from standard forms and submissions.
• Form actions and Submission actions are separate and have separate actions and tree paths. Form actions are when that actual form is created, updated, etc. Submission actions are when instances of that form/the form's data are created, submitted, etc.