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.
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.
Example:
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.
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.
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.
Example:
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
Thank you!