While bridges are a way of form developers to access, use, and display data, webhooks are a different part of the integration picture. They allow Platform admins to have a platform event, such as user creation, user addition onto a team, form creation, or submission sumbit, 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.
Webhooks send information to a specified URL when an event happens. The information provided depends on the event.
The Kinetic Platform provides the following webhook events:
And any of these events can be set up in one or many webhooks. You may need many webhooks for one event, because you may want a filter on a particular event, to make one thing happen in one case and something else happen in another.
You may also have one or many events that don't have any actions for any particular space or kapp. This is ok too, depending on what your workflow requirements are.
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.
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.