Webhook V2

Description

The Webhook trigger allows a HTTP request to initiate a Flow defined in Extension Kit Portal. In a typical scenario this trigger would be utilized to allow a workflow defined somewhere else to continue execution in a U4EC Flow. More details are available for such a scenario at Appendix A: LogicApps.

Basic Configuration

Webhook config

An unique descriptive name needs to be provided for a Webhook trigger.

Authentication

Optionally the endpoint can be secured, using one of the following authentication method

Basic

Webhook basic authentication

An User name and a Password needs to be specified. When calling this endpoint, an authentication header needs to be provided as described at the following link

U4IDS (connected)

Webhook U4IDS authentication

When calling an endpoint that is secured by U4IDS, a token has to be sent in the authorization header, that is obtained from U4IDS. Optionally some claims can be requested to be present in the token. When setting up such claims, in the values we can use the macros {{triggerId}} and {{tenant}}, they will be replaced with their actual values automatically.

Azure Active Directory

Webhook AAD authentication

When calling an endpoint that is secured by U4IDS, a token has to be sent in the authorization header, that is obtained from Azure Active Directory. Optionally some claims can be requested to be present in the token. When setting up such claims, in the values we can use the macros {{triggerId}} and {{tenant}}, they will be replaced with their actual values automatically.

Request Body

Webhook Request body

Webhook's payload can be specified in this section. The dropdown menu allows to specify the content type of it:

Primary response

Response from Webhook can be customized. There are two configuration sections to customize the response. Primary Response configuration allows the user to configure the response to POST requests.

Webhook primary response

Secondary response

Additional verbs can be added to Webhook V2 response under the Secondary Response section. The supported methods are OPTIONS, GET and PUT. If the webhook is called with a method that is not configured the response will be 405 - Method not allowed. The rest of the parameters are the same than Primary Response configuration. Webhook secondary response

Even though Webhook V2 supports both primary and secondary response configurations, only POST requests trigger the flow. OPTIONS, GET and PUT requests are meant to be used for validating subscription systems such as Event Grid.

Templating system

Webhook supports templating system to use the incoming request to build a custom response. Supported templates are:

Example: Subscribe Extension Kit Flow to EventGrid

Custom response in conjunction with templating system can be used to validate event source subscriptions. It means that a Extension Kit Flow can be subscribed to a event source so it will be triggered when new events occurs in the source.

Following configuration can be used to subscribe a Flow to Event Grid with Cloud Event Schema v1.0.

Webhook Event Grid subscritpion

Input

The request that is posted to the endpoint.

Output

The original input received including headers, query and body.

Webhook output

Custom data

After saving a flow that uses the Webhook trigger, the system will generate 2 URI's. The first one, Address is the URI to which the data needs to be pushed by the external application. The second one, Metadata Address provides an endpoint that returns the metadata in Swagger / OpenAPI format. This metadata address can be provided for example when using the Logic App's Http + Swagger connector.

Webhook config

NOTE: Custom data will be cleared if the flow is disabled or trigger is updated.