Webhook (v2)

Description

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

Basic Configuration

An unique descriptive name must be provided for a Webhook trigger.

Authentication

Optionally the endpoint can be secured using one of the following authentication methods.

NOTE: If you do not want to secure your enpoint, select None in the Authentication options.

Basic

A User name and Password must be specified. When calling this endpoint, an authentication header must be provided as described in the IETF document The 'Basic' HTTP Authentication Scheme

U4IDS (connected)

When calling an endpoint that is secured by U4IDS, a token must 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}}, and they will be replaced with their actual values automatically.

Azure Active Directory

When calling an endpoint that is secured by U4IDS, a token must 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}}, and they will be replaced with their actual values automatically.

Request Body

You specify the Webhook payload in this section. The dropdown menu allows you to specify the content type:

• JSON: This is the default option. You can set up a schema that will be shown in the trigger's configuration.
• XML: Flow will accept XML as payload, no schema needed.
• Text: Flow will accept text as payload, no schema needed

Primary response

You can customise the response from the Webhook by configuring the response to POST requests.

• Status Code: By default the Webhook responds with a 204 No Content code. You can change this to respond with a 200 OK or 202 Accepted code instead.

• Headers: The response can include custom headers specifying key and value for each one.

• Body: The response can include a custom body response.

Secondary response

You can add verbs to the 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 as the Primary response configuration.

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 to use the incoming request to build a custom response. Supported templates are:

• Query: following expression {{step0.request.query[QueryKey]}} will be replaced by the value of the query parameter if present in the incoming request.

• Header: following expression {{step0.request.header[Header]}} will be replaced by the value of the header if present in the incoming request.

• Body: following expression {{step0.request.body.propertyPath}} will be replaced by the value of the payload if present in the incoming request. It supports simple/deep properties and array values.

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.

You can use the following configuration to subscribe a Flow to Event Grid with Cloud Event Schema v1.0.

Input

The request that is posted to the endpoint.

Output

The original input received including headers, query and body.

Extra data

After saving a flow that uses the Webhook trigger, the system generates the following exrtra data.

• Address is the URI to which the data needs to be pushed by the external application.
• 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.
• TriggerID is the unique ID of the trigger.

NOTE: The generated extra data Address, Metadata address and TriggerID remains static and does not change if the flow is disabled or the Webhook (V2) trigger is updated.

Advanced configuration - Mutual TLS

Mutual TLS, also known as mTLS or 2-way SSL, is a technique for two-way authentication. mTLS ensures that the parties at each end of a connection are who they claim to be. The information within their respective TLS certificates provides additional verification.

In order to enable mTLS for the Extension Kit Webhook trigger, access the Webook Trigger> Advanced configuration> Client Certificate and select your certificate of choice. For more information regarding certificates and how to add a new one, please refer to the certificates documentation.

Note: A flow that is being triggered with an expired certificate, or whose validity has not yet started, will not run. Additionally, a Flow being activated by a certificate that does not match the webhook setup will also not run.

WARNING: Incoming webhook calls must be comprised of their certificate and respective private key. The private key is not saved or stored and does not reach the Extension Kit area. It is only used to guarantee the ownership of the matching inbound certificate during the process.