Webhooks (External)
Introduction
JourneyApps supports outgoing webhooks that allow remote endpoints to be called when data changes are made.
Webhooks can be configured for a specific model in your Data Model, which will then be triggered when certain conditions are met.
Configuration
Webhooks are defined in the Data Model of your app, in OXIDE.
To define webhooks to be sent when a specific type of object is created or saved, add a <webhook/>
element at the end of a <model/>
definition.
Webhooks can be defined for integrating with internal JourneyApps systems, specifically CloudCode, or with external services.
For configuring webhooks with CloudCode, see the CloudCode -> Webhooks section.
All webhook requests include a signature that can be used to verify the authenticity without needing to configure any shared secrets.
Webhooks to External Systems
The configuration options in the <webhook/>
tag are as follows:
Configuration Option | Description |
---|---|
| The type of webhook, this can be either |
| Mandatory name for the webhook. |
| Specify "cloudcode" if the webhook should trigger a CloudCode task. See the CloudCode -> Webhooks section for further details. |
| The CloudCode task name, if the receiver was specified as "cloudcode". |
Note: Only type=""
and name=""
are relevant for webhooks to external systems.
Once the webhook has been defined in OXIDE, the endpoint needs to be configured in the Backend. The webhooks will not fire until this has been completed.
This is done through the "Manage Webhooks" link in the user drop-down menu (only available for elevated super-users). All external webhooks will be listed under the "User hooks" section. The "Manage" action for each webhook allows the webhook to be enabled and the endpoint URL to be specified.
Example: External Webhook
In the example below, we trigger a request to http://requestb.in/1mwlqhx1
every time that an object of type resource
is saved.
The relevant headers for the resulting POST request are as follows:
Header | Value |
---|---|
| Webhook Verification 1 |
| txho18dwBF2BNQpUdh6ji8govTy/kC cE6kBiYQg\ntTE/9uFS2OvRCy8yJa3 oT3HtdLMqjb2W7CLVlY\nctdenZnQH tLW7MRtM/KZYNP4h2dwbR/yAbeA\nh XPrWGGizSaSwH+tL6hjNmldvp3jMHi C2E8kK\nvz5z5BkQ0BSII2rLiVO3HX jg4SOlzw/VXMpv8g2\nFtCwaUOA2by kAm/LmPNY/nn2wtLR3rKOhleeA\noh 2CEWXM+cx05K01afbFV9oabjgLWXWc TmV\nu/c9ceeUd210SKudpIY3i7lma JWort8w1vXU5SS\ns+wx12KUGMMlDY mCgMWU0cPxP7KoelLaX+\nuUuw7JMg== |
| b1a6704741054a48363b4e02d89f7d6243b1adf54aa0fa4dd338c5d2949028b4 |
|
|
|
|
(Purely informational) |
The JSON body for the request is as follows:
The values in sequence
are large numbers, so make sure that you are using big ints / doubles / similar. Something like json-bigint is required for JavaScript. Take care when testing with services such as requestbin, since they often truncate/round these values.
Conditions and Embedded Fields
Webhook definitions can optionally contain a number of field
elements for specifying triggering conditions and embedded attachments or belongs-to objects. The webhook will only trigger once all conditions have been met, regardless of the type of webhook.
The configuration options for the field
element are as follows:
Configuration Option | Description |
---|---|
| The name of the field on which to operate. |
| If the field is required or not in order to trigger the webhook ( |
| If the belongs-to related object or attachment should be embedded in the webhook request ( |
| Set |
In the example below, we trigger the event for the asset_ready
webhook the first time that the asset_photo
attachment field is set and uploaded and the user
(belongs-to
relationship) is set. The asset_photo
attachment field is embedded in the webhook request.
Last updated