Connecting an Azure Logic App to a local Web API
RSS feed
Date: May 20, 2020
Tags: azure
Share: Share on Twitter
NOTE: Technology changes fast, so some of the images and/or code in this article maybe be out of date. Feel free to leave a comment if you notice something that needs updating.
Have you ever wanted to develop with Azure Logic Apps, but struggled to test things out until you’ve deployed? Don’t worry, you’re not alone. Logic Apps are an extremely powerful low-code/no-code solution for many problems, but do have some inherent limitations that may make things tricky when you’re just starting out your project locally. In this article, I’ll show you how you can test your Logic Apps with your on-prem systems using a few cool tools and services.

When it comes to Logic Apps, Azure has a ton of connectors to allow you to design your automation workflows to integrate to all sorts of systems. Nearly every major Microsoft service is there, along with a slew of 3rd party components and services. And if those don’t fit the bill, you can develop your own connectors to do just about anything you need to.

A common step in Logic App integration is to develop a Web API to interact with other systems. The API usually handles the database connections, exposing methods for apps to consume. Developing that API locally almost always is the easiest path, especially when you’re working with internal database/systems. Add a Logic App into the mix, and now we have a challenge. How will our Logic App be able to access the local API? Unlike many other Azure services, Logic Apps aren’t assigned a static IP address. This means they can’t be let through a firewall/gateway, causing network admins to lose it when it comes to keeping them secure.

To get around this, we can easily 2 components to the mix, allowing us to connect our local Web API to the Logic App. These are the ngrok utility and an Azure API Management Service. ngrok allows us to create a secure, temporary tunnel to our local Web API, with a unique URL. APIM allows us to then use that URL for an endpoint for the Logic App to call, allowing us to call our methods. Because APIM’s can have static IPs, they can easily be whitelisted for any networks.

Here’s an overview of the process.

It’s a pretty simple process, but one that may save you a lot of time during your development by allowing you to test your Web APIs with your Logic Apps. Let me show you how to set it all up.

Azure Logic Apps documentation

Create Web API

First, you’re going to need a local service to connect to. In my case, I opted for a Web API, but really it could be anything you like. You just need something that runs on your localhost web server.

Here’s my simple Web API. I’m using EF to connect to a local SQL server to work with order data from the always exciting Northwind DB.

Running the project launches the Web API on http://localhost:5000 and returns all my order data.


I leave the API running locally throughout the process.

Run ngrok

With the Web API running locally, I can fire up ngrok to do its magic. This free tool makes accessing your local services from the internet a simple process. I use it a lot when developing to test connectivity and ensure functionality.

ngrok documentation

I run the utility, mapping the tunnel to port 5000 on my localhost.

At this point, I have a very awesome API running locally, which is also accessible using the URL. ngrok will always create a new URL when the utility is executed, so you don’t have to worry about someone hitting your API.


I will leave ngrok running to keep the new tunnel active, as well as monitor any connections (calls to my local API).

Create APIM

With the API running, I create a new Azure API Management Service. This process may take a little while to complete, and once done you can add your API to the service. APIMs are awesome for exposing your APIs to the world and controlling access through separate subscriptions and quotes.

Azure APIM Management documentation

Here are the settings for the Web API in my APIM.

Note that I have my URL as the Web Service URL, as well as the Subscription required option selected. This will prevent unwanted calls to my APIM.

After adding the API, I then add an operation for my orders method.

You could add a lot more operations, depending on your API.

Create Logic App

With the API and APIM running, I’m ready to create my Logic App. I start with a simple Http Request trigger. I will be passing my APIM subscription key in the body to the Logic App, so I add the schema to the configuration.

Next, I add a step to access my APIM. This is one of the built-in connectors and makes selecting your API a very simple process. I choose my newly registered API.

After selecting my API, I select the Orders operation.

I then add a Response step and select the Body of the APIM step as the return value. This will pass the API response JSON through to the end of the Logic App.

Here is the full Logic App with all the steps, for reference.


Now, let’s see if this thing works. To test the process, I use Postman to call my Logic App, passing my subscription key in the body. I make a POST to my Logic App URL, passing the key, and get the list of orders returned.

Postman documentation

In my ngrok utility, I have a new HTTP Request to the GET /orders method. This proves that the local API was accessed and returned a response.

In my Logic App run history, I view the successful execution, including the response that was returned to Postman.

This test tells me that the Logic App was called from Postman correctly, accessed my APIM, traversed the ngrok dynamic tunnel, and called my local API to get the data from the local database. Woot!

Moving forward

When blending local development with cloud resources, you’ll often encounter challenges where system X can’t get to the system Y. By leveraging ngrok and APIM, you can easily connect on-prem and cloud systems, allowing you to debug and test your code without a full-blown deployment. This can save you a ton of time and amaze your friends. Good luck!