Call, trigger, or nest logic apps by using HTTPS endpoints in Azure Logic Apps

To make your logic app callable through a URL and able to receive inbound requests from other services, you can natively expose a synchronous HTTPS endpoint by using a request-based trigger on your logic app. With this capability, you can call your logic app from other logic apps and create a pattern of callable endpoints. To set up a callable endpoint for handling inbound calls, you can use any of these trigger types:

This article shows how to create a callable endpoint on your logic app by using the Request trigger and call that endpoint from another logic app. All principles apply identically to the other trigger types that you can use to receive inbound requests.

For more information about security, authorization, and encryption for inbound calls to your logic app, such as Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), Azure Active Directory Open Authentication (Azure AD OAuth), exposing your logic app with Azure API Management, or restricting the IP addresses that originate inbound calls, see Secure access and data - Access for inbound calls to request-based triggers.

Prerequisites

Create a callable endpoint

  1. Sign in to the Azure portal. Create and open a blank logic app in the Logic App Designer.

  2. Under the search box, select Built-in. In the search box, enter request as your filter. From the triggers list, select When a HTTP request is received.

    Find and select the Request trigger

  3. Optionally, in the Request Body JSON Schema box, you can enter a JSON schema that describes the payload or data that you expect the trigger to receive.

    The designer uses this schema to generate tokens that represent trigger outputs. You can then easily reference these outputs throughout your logic app's workflow. Learn more about tokens generated from JSON schemas.

    For this example, enter this schema:

       {
       "type": "object",
       "properties": {
          "address": {
             "type": "object",
             "properties": {
                "streetNumber": {
                   "type": "string"
                },
                "streetName": {
                   "type": "string"
                },
                "town": {
                   "type": "string"
                },
                "postalCode": {
                   "type": "string"
                }
             }
          }
       }
    }
    

    Provide JSON schema for the Request action

    Or, you can generate a JSON schema by providing a sample payload:

    1. In the Request trigger, select Use sample payload to generate schema.

    2. In the Enter or paste a sample JSON payload box, enter your sample payload, for example:

      {
         "address": {
            "streetNumber": "00000",
            "streetName": "AnyStreet",
            "town": "AnyTown",
            "postalCode": "11111-1111"
        }
      }
      
    3. When you're ready, select Done.

      The Request Body JSON Schema box now shows the generated schema.

  4. Save your logic app.

    The HTTP POST URL box now shows the generated callback URL that other services can use to call and trigger your logic app. This URL includes query parameters that specify a Shared Access Signature (SAS) key, which is used for authentication.

    Generated callback URL for endpoint

  5. To copy the callback URL, you have these options:

    • To the right of the HTTP POST URL box, select Copy Url (copy files icon).

    • Make this call by using the method that the Request trigger expects. This example uses the POST method:

      POST https://management.azure.com/{logic-app-resource-ID}/triggers/{endpoint-trigger-name}/listCallbackURL?api-version=2016-06-01

    • Copy the callback URL from your logic app's Overview pane.

      1. On your logic app's menu, select Overview.

      2. In the Summary section, select See trigger history.

        Get endpoint URL from Azure portal

      3. Under Callback url [POST], copy the URL:

        Copy endpoint URL from Azure portal

Select expected request method

By default, the Request trigger expects a POST request. However, you can specify a different method that the caller must use, but only a single method.

  1. In the Request trigger, open the Add new parameter list, and select Method, which adds this property to the trigger.

    Add "Method" property to trigger

  2. From the Method list, select the method that the trigger should expect instead. Or, you can specify a custom method.

    For example, select the GET method so that you can test your endpoint's URL later.

    Select request method expected by the trigger

Pass parameters through endpoint URL

When you want to accept parameter values through the endpoint's URL, you have these options:

  • Accept values through GET parameters or URL parameters.

    These values are passed as name-value pairs in the endpoint's URL. For this option, you need to use the GET method in your Request trigger. In a subsequent action, you can get the parameter values as trigger outputs by using the triggerOutputs() function in an expression.

  • Accept values through a relative path for parameters in your Request trigger.

    These values are passed through a relative path in the endpoint's URL. You also need to explicitly select the method that the trigger expects. In a subsequent action, you can get the parameter values as trigger outputs by referencing those outputs directly.

Accept values through GET parameters

  1. In the Request trigger, open the Add new parameter list, add the Method property to the trigger, and select the GET method.

    For more information, see Select expected request method.

  2. Under the Request trigger, add the action where you want to use the parameter value. For this example, add the Response action.

    1. Under the Request trigger, select New step > Add an action.

    2. Under Choose an action, in the search box, enter response as your filter. From the actions list, select the Response action.

  3. To build the triggerOutputs() expression that retrieves the parameter value, follow these steps:

    1. Click inside the Response action's Body property so that the dynamic content list appears, and select Expression.

    2. In the Expression box, enter this expression, replacing parameter-name with your parameter name, and select OK.

      triggerOutputs()['queries']['parameter-name']

      Add "triggerOutputs()" expression to trigger

      In the Body property, the expression resolves to the triggerOutputs() token.

      Resolved "triggerOutputs()" expression

      If you save the logic app, navigate away from the designer, and return to the designer, the token shows the parameter name that you specified, for example:

      Resolved expression for parameter name

      In code view, the Body property appears in the Response action's definition as follows:

      "body": "@{triggerOutputs()['queries']['parameter-name']}",

      For example, suppose that you want to pass a value for a parameter named postalCode. The Body property specifies the string, Postal Code: with a trailing space, followed by the corresponding expression:

      Add example "triggerOutputs()" expression to trigger

  4. To test your callable endpoint, copy the callback URL from the Request trigger, and paste the URL into another browser window. In the URL, add the parameter name and value following the question mark (?) to the URL in the following format, and press Enter.

    ...?{parameter-name=parameter-value}&api-version=2016-10-01...

    https://prod-07.westus.logic.azure.com:433/workflows/{logic-app-resource-ID}/triggers/manual/paths/invoke?{parameter-name=parameter-value}&api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={shared-access-signature}

    The browser returns a response with this text: Postal Code: 123456

    Response from sending request to callback URL

  5. To put the parameter name and value in a different position within the URL, make sure to use the ampersand (&) as a prefix, for example:

    ...?api-version=2016-10-01&{parameter-name=parameter-value}&...

    This example shows the callback URL with the sample parameter name and value postalCode=123456 in different positions within the URL:

    • 1st position: https://prod-07.westus.logic.azure.com:433/workflows/{logic-app-resource-ID}/triggers/manual/paths/invoke?postalCode=123456&api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={shared-access-signature}

    • 2nd position: https://prod-07.westus.logic.azure.com:433/workflows/{logic-app-resource-ID}/triggers/manual/paths/invoke?api-version=2016-10-01&postalCode=123456&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={shared-access-signature}

Note

If you want to include the hash or pound symbol (#) in the URI, use this encoded version instead: %25%23

Accept values through a relative path

  1. In the Request trigger, open the Add new parameter list, and select Relative path, which adds this property to the trigger.

    Add "Relative path" property to trigger

  2. In the Relative path property, specify the relative path for the parameter in your JSON schema that you want your URL to accept, for example, /address/{postalCode}.

    Specify the relative path for the parameter

  3. Under the Request trigger, add the action where you want to use the parameter value. For this example, add the Response action.

    1. Under the Request trigger, select New step > Add an action.

    2. Under Choose an action, in the search box, enter response as your filter. From the actions list, select the Response action.

  4. In the Response action's Body property, include the token that represents the parameter that you specified in your trigger's relative path.

    For example, suppose that you want the Response action to return Postal Code: {postalCode}.

    1. In the Body property, enter Postal Code: with a trailing space. Keep your cursor inside the edit box so that the dynamic content list remains open.

    2. In the dynamic content list, from the When a HTTP request is received section, select the postalCode token.

      Add the specified parameter to response body

      The Body property now includes the selected parameter:

      Example response body with parameter

  5. Save your logic app.

    In the Request trigger, the callback URL is updated and now includes the relative path, for example:

    https://prod-07.westus.logic.azure.com/workflows/{logic-app-resource-ID}/triggers/manual/paths/invoke/address/{postalCode}?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={shared-access-signature}

  6. To test your callable endpoint, copy the updated callback URL from the Request trigger, paste the URL into another browser window, replace {postalCode} in the URL with 123456, and press Enter.

    The browser returns a response with this text: Postal Code: 123456

    Response from sending request to callback URL

Note

If you want to include the hash or pound symbol (#) in the URI, use this encoded version instead: %25%23

Call logic app through endpoint URL

After you create the endpoint, you can trigger the logic app by sending an HTTPS request to the endpoint's full URL. Logic apps have built-in support for direct-access endpoints.

Tokens generated from schema

When you provide a JSON schema in the Request trigger, the Logic App Designer generates tokens for the properties in that schema. You can then use those tokens for passing data through your logic app workflow.

For example, if you add more properties, such as "suite", to your JSON schema, tokens for those properties are available for you to use in the later steps for your logic app. Here is the complete JSON schema:

   {
   "type": "object",
   "properties": {
      "address": {
         "type": "object",
         "properties": {
            "streetNumber": {
               "type": "string"
            },
            "streetName": {
               "type": "string"
            },
            "suite": {
               "type": "string"
            },
            "town": {
               "type": "string"
            },
            "postalCode": {
               "type": "string"
            }
         }
      }
   }
}

Create nested logic apps

You can nest workflows into your logic app by adding other logic apps that can receive requests. To include these logic apps, follow these steps:

  1. Under the step where you want to call another logic app, select New step > Add an action.

  2. Under Choose an action, select Built-in. In the search box, enter logic apps as your filter. From the actions list, select Choose a Logic Apps workflow.

    Nest logic app inside current logic app

    The designer shows the eligible logic apps for you to select.

  3. Select the logic app to call from your current logic app.

    Select logic app to call from current logic app

Reference content from an incoming request

If the incoming request's content type is application/json, you can reference the properties in the incoming request. Otherwise, this content is treated as a single binary unit that you can pass to other APIs. To reference this content inside your logic app's workflow, you need to first convert that content.

For example, if you're passing content that has application/xml type, you can use the @xpath() expression to perform an XPath extraction, or use the @json() expression for converting XML to JSON. Learn more about working with supported content types.

To get the output from an incoming request, you can use the @triggerOutputs expression. For example, suppose you have output that looks like this example:

{
   "headers": {
      "content-type" : "application/json"
   },
   "body": {
      "myProperty" : "property value"
   }
}

To access specifically the body property, you can use the @triggerBody() expression as a shortcut.

Respond to requests

Sometimes you want to respond to certain requests that trigger your logic app by returning content to the caller. To construct the status code, header, and body for your response, use the Response action. This action can appear anywhere in your logic app, not just at the end of your workflow. If your logic app doesn't include a Response action, the endpoint responds immediately with the 202 Accepted status.

For the original caller to successfully get the response, all the required steps for the response must finish within the request timeout limit unless the triggered logic app is called as a nested logic app. If no response is returned within this limit, the incoming request times out and receives the 408 Client timeout response.

For nested logic apps, the parent logic app continues to wait for a response until all the steps are completed, regardless of how much time is required.

Construct the response

In the response body, you can include multiple headers and any type of content. For example, this response's header specifies that the response's content type is application/json and that the body contains values for the town and postalCode properties, based on the JSON schema described earlier in this topic for the Request trigger.

Provide response content for HTTPS Response action

Responses have these properties:

Property (Display) Property (JSON) Description
Status Code statusCode The HTTPS status code to use in the response for the incoming request. This code can be any valid status code that starts with 2xx, 4xx, or 5xx. However, 3xx status codes are not permitted.
Headers headers One or more headers to include in the response
Body body A body object that can be a string, a JSON object, or even binary content referenced from a previous step

To view the JSON definition for the Response action and your logic app's complete JSON definition, on the Logic App Designer toolbar, select Code view.

"Response": {
   "type": "Response",
   "kind": "http",
   "inputs": {
      "body": {
         "postalCode": "@triggerBody()?['address']?['postalCode']",
         "town": "@triggerBody()?['address']?['town']"
      },
      "headers": {
         "content-type": "application/json"
      },
      "statusCode": 200
   },
   "runAfter": {}
}

Q & A

Q: What about URL security?

A: Azure securely generates logic app callback URLs by using Shared Access Signature (SAS). This signature passes through as a query parameter and must be validated before your logic app can run. Azure generates the signature using a unique combination of a secret key per logic app, the trigger name, and the operation that's performed. So unless someone has access to the secret logic app key, they cannot generate a valid signature.

Important

For production and higher security systems, we strongly advise against calling your logic app directly from the browser for these reasons:

  • The shared access key appears in the URL.
  • You can't manage security content policies due to shared domains across Azure Logic Apps customers.

For more information about security, authorization, and encryption for inbound calls to your logic app, such as Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), Azure Active Directory Open Authentication (Azure AD OAuth), exposing your logic app with Azure API Management, or restricting the IP addresses that originate inbound calls, see Secure access and data - Access for inbound calls to request-based triggers.

Q: Can I configure callable endpoints further?

A: Yes, HTTPS endpoints support more advanced configuration through Azure API Management. This service also offers the capability for you to consistently manage all your APIs, including logic apps, set up custom domain names, use more authentication methods, and more, for example:

Next steps