Subscribe and wait for events to run workflows using HTTP webhooks in Azure Logic Apps
Applies to: Azure Logic Apps (Consumption + Standard)
Rather than use a trigger that regularly checks or polls a service endpoint or action that calls that endpoint, you can use an HTTP Webhook trigger or action that subscribes to a service endpoint, waits for specific events, and runs specific actions in your workflow.
Here are some example webhook-based workflows:
- Wait for an event to arrive from Azure Event Hubs before triggering a workflow run.
- Wait for an approval before continuing a workflow.
This guide shows how to use the HTTP Webhook trigger and Webhook action so that your workflow can receive and respond to events at a service endpoint.
How do webhooks work?
A webhook trigger is event-based, which doesn't depend on checking or polling regularly for new data or events. After you add a webhook trigger to an empty workflow and then save the workflow, or after you re-enable a disabled logic app resource, the webhook trigger subscribes to the specified service endpoint by registering a callback URL with that endpoint. The trigger then waits for that service endpoint to call the URL, which fires the trigger and starts the workflow. Similar to the Request trigger, a webhook trigger fires immediately. The webhook trigger also remains subscribed to the service endpoint unless you manually take the following actions:
- Change the trigger's parameter values.
- Delete the trigger and then save your workflow.
- Disable your logic app resource.
Similar to the webhook trigger, a webhook action works is also event-based. After you add a webhook action to an existing workflow and then save the workflow, or after you re-enable a disabled logic app resource, the webhook action subscribes to the specified service endpoint by registering a callback URL with that endpoint. When the workflow runs, the webhook action pauses the workflow and waits until the service endpoint calls the URL before the workflow resumes running. A webhook action unsubscribes from the service endpoint when the following conditions occur:
- The webhook action successfully finishes.
- The workflow run is canceled while waiting for a response.
- Before a workflow run times out.
- You change any webhook action parameter values that are used as inputs by a webhook trigger.
For example, the Office 365 Outlook connector's Send approval email action is an example of webhook action that follows this pattern. You can extend this pattern into any service by using the webhook action.
For more information, see the following documentation:
For information about encryption, security, and authorization for inbound calls to your logic app, such as Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), or Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), see Secure access and data - Access for inbound calls to request-based triggers.
Connector technical reference
For more information about trigger and action parameters, see HTTP Webhook parameters.
Prerequisites
An Azure account and subscription. If you don't have an Azure subscription, sign up for a free Azure account.
The URL for an already deployed endpoint or API that supports the webhook subscribe and unsubscribe pattern for webhook triggers in workflows or webhook actions in workflows as appropriate
The Standard or Consumption logic app workflow where you want to wait for specific events at the target endpoint. To start with the HTTP Webhook trigger, create a logic app with a blank workflow. To use the HTTP Webhook action, start your workflow with any trigger that you want. This example uses the HTTP trigger as the first step.
Add an HTTP Webhook trigger
This built-in trigger calls the subscribe endpoint on the target service and registers a callback URL with the target service. Your workflow then waits for the target service to send an HTTP POST request to the callback URL. When this event happens, the trigger fires and passes any data in the request along to the workflow.
In the Azure portal, open your Standard logic app and blank workflow in the designer.
Follow these general steps to add the trigger named HTTP Webhook to your workflow.
This example renames the trigger to HTTP Webhook trigger so that the step has a more descriptive name. Also, the example later adds an HTTP Webhook action, and both names must be unique.
Provide the values for the HTTP Webhook trigger parameters that you want to use for the subscribe and unsubscribe calls.
Property Required Description Subscription - Method Yes The method to use when subscribing to the target endpoint Subscribe - URI Yes The URL to use for subscribing to the target endpoint Subscribe - Body No Any message body to include in the subscribe request. This example includes the callback URL that uniquely identifies the subscriber, which is your logic app, by using the @listCallbackUrl()expression to retrieve your logic app's callback URL.Unsubscribe - Method No The method to use when unsubscribing from the target endpoint Unsubscribe - URI No The URL to use for unsubscribing from the target endpoint Unsubscribe - Body No An optional message body to include in the unsubscribe request
Note: This property doesn't support using thelistCallbackUrl()function. However, the trigger automatically includes and sends the headers,x-ms-client-tracking-idandx-ms-workflow-operation-name, which the target service can use to uniquely identify the subscriber.Note
For the Unsubscribe - Method and Unsubscribe - URI properties, add them to your action by opening the Advanced parameters list.
For example, the following trigger includes the methods, URIs, and message bodies to use when performing the subscribe and unsubscribe operations.
If you need to use authentication, you can add the Subscribe - Authentication and Unsubscribe - Authentication properties. For more information about authentication types available for HTTP Webhook, see Add authentication to outbound calls.
Continue building your workflow with actions that run when the trigger fires.
When you're done, save your workflow. On the designer toolbar, select Save.
Saving your workflow calls the subscribe endpoint on the target service and registers the callback URL. Your workflow then waits for the target service to send an HTTP POST request to the callback URL. When this event happens, the trigger fires and passes any data in the request along to the workflow. If this operation completes successfully, the trigger unsubscribes from the endpoint, and your workflow continues to the next action.
Add an HTTP Webhook action
This built-in action calls the subscribe endpoint on the target service and registers a callback URL with the target service. Your workflow then pauses and waits for target service to send an HTTP POST request to the callback URL. When this event happens, the action passes any data in the request along to the workflow. If the operation completes successfully, the action unsubscribes from the endpoint, and your workflow continues to the next action.
This example uses the HTTP Webhook trigger as the first step.
In the Azure portal, open your Standard logic app and workflow in the designer.
Follow these general steps to add the action named HTTP Webhook to your workflow.
This example renames the action to HTTP Webhook action so that the step has a more descriptive name.
Provide the values for the HTTP Webhook action parameters, which are similar to the HTTP Webhook trigger parameters, that you want to use for the subscribe and unsubscribe calls.
Property Required Description Subscription - Method Yes The method to use when subscribing to the target endpoint Subscribe - URI Yes The URL to use for subscribing to the target endpoint Subscribe - Body No Any message body to include in the subscribe request. This example includes the callback URL that uniquely identifies the subscriber, which is your logic app, by using the @listCallbackUrl()expression to retrieve your logic app's callback URL.Unsubscribe - Method No The method to use when unsubscribing from the target endpoint Unsubscribe - URI No The URL to use for unsubscribing from the target endpoint Unsubscribe - Body No An optional message body to include in the unsubscribe request
Note: This property doesn't support using thelistCallbackUrl()function. However, the action automatically includes and sends the headers,x-ms-client-tracking-idandx-ms-workflow-operation-name, which the target service can use to uniquely identify the subscriber.Note
For the Unsubscribe - Method and Unsubscribe - URI properties, add them to your action by opening the Advanced parameters list.
For example, the following action includes the methods, URIs, and message bodies to use when performing the subscribe and unsubscribe operations.
To add other action properties, open the Advanced parameters list.
For example, if you need to use authentication, you can add the Subscribe - Authentication and Unsubscribe - Authentication properties. For more information about authentication types available for HTTP Webhook, see Add authentication to outbound calls.
When you're done, save your workflow. On the designer toolbar, select Save.
When this action runs, your workflow calls the subscribe endpoint on the target service and registers the callback URL. The workflow then pauses and waits for the target service to send an HTTP POST request to the callback URL. When this event happens, the action passes any data in the request along to the workflow. If the operation completes successfully, the action unsubscribes from the endpoint, and your workflow continues to the next action.
Trigger and action outputs
Here is more information about the outputs from an HTTP Webhook trigger or action, which returns this information:
| Property name | Type | Description |
|---|---|---|
| headers | object | The headers from the request |
| body | object | The object with the body content from the request |
| status code | int | The status code from the request |
| Status code | Description |
|---|---|
| 200 | OK |
| 202 | Accepted |
| 400 | Bad request |
| 401 | Unauthorized |
| 403 | Forbidden |
| 404 | Not Found |
| 500 | Internal server error. Unknown error occurred. |