Articles on: App Integrator

Webhook model

A distinctive feature of this type is - the “Requests” tab always has a trigger with the first request widget that cannot be deleted. It consists of the only one Response tab.

The reason is that the trigger responds to the incoming request, therefore it’s important to set up the response parser and select the content-type .

For webhook triggers to work, create a field with the Webhook type in the Connection Fields tab.

Check the Response to set up the tab. If you put a check on “Data array return”, the trigger in an automation will start for each entity when several objects (entities) arrive in the event.

Trigger filter

This trigger has opportunity to set up filter. The setting is available in the list of triggers. Use static values to set up the filter.

If the app uses one Webhook trigger, the filter setting is optional. This filter will start at any request. If there are more than one trigger, set up each trigger to make it work.

Specify filters with one or more conditions using AND/OR operator between them. In the left field of each condition specify the variable key of the request., Start the value with data. if the variable is in the body of the request, with headers. if it is in headers. Follow the usual mapping rules.

Select the condition operator in the middle field (equal, NOT equal, contains, etc.).

In the right field, enter the value to start the trigger.


Webhook catcher

If the trigger needs to catch an unknown dynamic set of fields, and mapping cannot be set, create a Webhook catcher in the app and connect it to the trigger.

Additional HTTP request

After the Response widget adding you can add another request widget to make a complete HTTP request. This request will start after receiving the event on the webhook URL substituting the data from the webhook. For example, when the webhook receives the event, but the request body contains only entity ID and type, make an additional request to receive more information about the entity.

Create a trigger field to store the value from the webhook (e.g., ID), then in the second outgoing request widget substitute this field in the URL. In this case, the main setting of the response parser takes place in the second widget, but the data from both requests can be stored and transferred to the automation.

Updated on: 07/12/2022

Was this article helpful?

Share your feedback


Thank you!