Call service endpoints over HTTP or HTTPS from Azure Logic Apps

With Azure Logic Apps and the built-in HTTP trigger or action, you can create automated tasks and workflows that send requests to service endpoints over HTTP or HTTPS. For example, you can monitor the service endpoint for your website by checking that endpoint on a specific schedule. When the specified event happens at that endpoint, such as your website going down, the event triggers your logic app's workflow and runs the actions in that workflow. If you want to receive and respond to inbound HTTPS calls instead, use the built-in Request trigger or Response action.

  • To check or poll an endpoint on a recurring schedule, add the HTTP trigger as the first step in your workflow. Each time that the trigger checks the endpoint, the trigger calls or sends a request to the endpoint. The endpoint's response determines whether your logic app's workflow runs. The trigger passes any content from the endpoint's response to the actions in your logic app.

  • To call an endpoint from anywhere else in your workflow, add the HTTP action. The endpoint's response determines how your workflow's remaining actions run.

This article shows how to add an HTTP trigger or action to your logic app's workflow.

Prerequisites

Add an HTTP trigger

This built-in trigger makes an HTTP call to the specified URL for an endpoint and returns a response.

  1. Sign in to the Azure portal. Open your blank logic app in Logic App Designer.

  2. Under the designer's search box, select Built-in. In the search box, enter http as your filter. From the Triggers list, select the HTTP trigger.

    Select HTTP trigger

    This example renames the trigger to "HTTP trigger" so that the step has a more descriptive name. Also, the example later adds an HTTP action, and both names must be unique.

  3. Provide the values for the HTTP trigger parameters that you want to include in the call to the target endpoint. Set up the recurrence for how often you want the trigger to check the target endpoint.

    Enter HTTP trigger parameters

    If you select an authentication type other than None, the authentication settings differ based on your selection. For more information about authentication types available for HTTP, see these topics:

  4. To add other available parameters, open the Add new parameter list, and select the parameters that you want.

  5. Continue building your logic app's workflow with actions that run when the trigger fires.

  6. When you're done, remember to save your logic app. On the designer toolbar, select Save.

Add an HTTP action

This built-in action makes an HTTP call to the specified URL for an endpoint and returns a response.

  1. Sign in to the Azure portal. Open your logic app in Logic App Designer.

    This example uses the HTTP trigger as the first step.

  2. Under the step where you want to add the HTTP action, select New step.

    To add an action between steps, move your pointer over the arrow between steps. Select the plus sign (+) that appears, and then select Add an action.

  3. Under Choose an action, select Built-in. In the search box, enter http as your filter. From the Actions list, select the HTTP action.

    Select HTTP action

    This example renames the action to "HTTP action" so that the step has a more descriptive name.

  4. Provide the values for the HTTP action parameters that you want to include in the call to the target endpoint.

    Enter HTTP action parameters

    If you select an authentication type other than None, the authentication settings differ based on your selection. For more information about authentication types available for HTTP, see these topics:

  5. To add other available parameters, open the Add new parameter list, and select the parameters that you want.

  6. When you're done, remember to save your logic app. On the designer toolbar, select Save.

Transport Layer Security (TLS)

Based the target endpoint's capability, outbound calls support Transport Layer Security (TLS), which was previously Secure Sockets Layer (SSL), versions 1.0, 1.1, and 1.2. Logic Apps negotiates with the endpoint over using the highest supported version possible.

For example, if the endpoint supports 1.2, the HTTP connector uses 1.2 first. Otherwise, the connector uses the next highest supported version.

Self-signed certificates

  • For logic apps in the global, multi-tenant Azure environment, the HTTP connector doesn't permit self-signed TLS/SSL certificates. If your logic app makes an HTTP call to a server and presents a TLS/SSL self-signed certificate, the HTTP call fails with a TrustFailure error.

  • For logic apps in an integration service environment (ISE), the HTTP connector permits self-signed certificates for TLS/SSL handshakes. However, you must first enable self-signed certificate support for an existing ISE or new ISE by using the Logic Apps REST API, and install the public certificate at the TrustedRoot location.

Content with multipart/form-data type

To handle content that has multipart/form-data type in HTTP requests, you can add a JSON object that includes the $content-type and $multipart attributes to the HTTP request's body by using this format.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

For example, suppose you have a logic app that sends an HTTP POST request for an Excel file to a website by using that site's API, which supports the multipart/form-data type. Here's how this action might look:

Multipart form data

Here is the same example that shows the HTTP action's JSON definition in the underlying workflow definition:

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

Asynchronous request-response behavior

By default, all HTTP-based actions in Azure Logic Apps follow the standard asynchronous operation pattern. This pattern specifies that after an HTTP action calls or sends a request to an endpoint, service, system, or API, the receiver immediately returns a "202 ACCEPTED" response. This code confirms that the receiver accepted the request but hasn't finished processing. The response can include a location header that specifies the URL and a refresh ID that the caller can use to poll or check the status for the asynchronous request until the receiver stops processing and returns a "200 OK" success response or other non-202 response. However, the caller doesn't have to wait for the request to finish processing and can continue to run the next action. For more information, see Asynchronous microservice integration enforces microservice autonomy.

  • In the Logic App Designer, the HTTP action, but not trigger, has an Asynchronous Pattern setting, which is enabled by default. This setting specifies that the caller doesn't wait for processing to finish and can move on to the next action but continues checking the status until processing stops. If disabled, this setting specifies that the caller waits for processing to finish before moving on to the next action.

    To find this setting, follow these steps:

    1. On the HTTP action's title bar, select the ellipses (...) button, which opens the action's settings.

    2. Find the Asynchronous Pattern setting.

      "Asynchronous Pattern" setting

  • The HTTP action's underlying JavaScript Object Notation (JSON) definition implicitly follows the asynchronous operation pattern.

Disable asynchronous operations

Sometimes, you might want to the HTTP action's asynchronous behavior in specific scenarios, for example, when you want to:

Turn off Asynchronous Pattern setting

  1. In the Logic App Designer, on the HTTP action's title bar, select the ellipses (...) button, which opens the action's settings.

  2. Find the Asynchronous Pattern setting, turn the setting to Off if enabled, and select Done.

    Disable the "Asynchronous Pattern" setting

Disable asynchronous pattern in action's JSON definition

In the HTTP action's underlying JSON definition, add the "DisableAsyncPattern" operation option to the action's definition so that the action follows the synchronous operation pattern instead. For more information, see also Run actions in a synchronous operation pattern.

Avoid HTTP timeouts for long-running tasks

HTTP requests have a timeout limit. If you have a long-running HTTP action that times out due to this limit, you have these options:

  • Disable the HTTP action's asynchronous operation pattern so that the action doesn't continually poll or check the request's status. Instead, the action waits for the receiver to respond with the status and results after the request finishes processing.

  • Replace the HTTP action with the HTTP Webhook action, which waits for the receiver to respond with the status and results after the request finishes processing.

Disable checking location headers

Some endpoints, services, systems, or APIs return a "202 ACCEPTED" response that don't have a location header. To avoid having an HTTP action continually check the request status when the location header doesn't exist, you can have these options:

  • Disable the HTTP action's asynchronous operation pattern so that the action doesn't continually poll or check the request's status. Instead, the action waits for the receiver to respond with the status and results after the request finishes processing.

  • Replace the HTTP action with the HTTP Webhook action, which waits for the receiver to respond with the status and results after the request finishes processing.

Known issues

Omitted HTTP headers

If an HTTP trigger or action includes these headers, Logic Apps removes these headers from the generated request message without showing any warning or error:

  • Accept-*
  • Allow
  • Content-* with these exceptions: Content-Disposition, Content-Encoding, and Content-Type
  • Cookie
  • Expires
  • Host
  • Last-Modified
  • Origin
  • Set-Cookie
  • Transfer-Encoding

Although Logic Apps won't stop you from saving logic apps that use an HTTP trigger or action with these headers, Logic Apps ignores these headers.

Connector reference

For more information about trigger and action parameters, see these sections:

Output details

Here is more information about the outputs from an HTTP trigger or action, which returns this information:

Property Type Description
headers JSON object The headers from the request
body JSON object The object with the body content from the request
status code Integer 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.

Next steps