How to Expose and Protect Logic App Using Azure API Management whitepaper

With the Azure API Management (Azure APIM), we can expose Logic Apps in a managed way, allowing us to take control through policies, add security, provide decoupling between frontend and backend, and much more.

The first thing you should be aware of is that out-of-the-box, you can only expose an Azure Logic App that exposes an HTTP endpoint on your APIM and are inside your Azure Subscription. Also, the various options for Azure API Management Monitoring to ensure your resource is healthy and working as expected.

Once you expose Logic Apps through APIM, there are several options to protect the Logic Apps regarding authorized clients and IP address restrictions.

In this whitepaper, I try to explain the step-by-step process of exposing and protecting the Logic Apps with APIM.

What’s in store for you?

This whitepaper will give you a detailed understanding of the following:

• Expose and restrict access to the Logic App
  • Step-by-step process on how you can publish your Logic App in Azure API Management (APIM), or if you prefer, how you can protect your Logic App using APIM.
• How to limit incoming IP addresses for a specific Logic App
  • How you will be able to protect your Logic App from improper access, i.e., if we are exposing the Logic App thru APIM we may want to enforce that all the communication to go through APIM and restrict access to the Logic App, for example avoiding direct call to the Logic App (without passing thru APIM)
• Exposing multiple Logic Apps in a single API
  • In this chapter I will address the folowing questions:
    • If we have one or more Logic Apps that we want to expose on APIM as an API, do we need to have several APIs with one operation? Or can we combine them in a unique API?
    • What about implementing a proper REST naming convention on these APIs? Is it possible
• Delete a Logic Apps expose as an API or Operation
  • And finally how we can deles a Logic App expose as an API. You may be thinking that is basic information and a straightforward task. Indeed it is, and you are right that it is an effortless and straightforward operation, at least at first glance. But like most things, nothing is that simple if you look closer.
• Descriptions
  • How you can easily document your API operations without requiring the traditional Word/PDF documents that can quickly become deprecated and obsolete. We will address: The global API Description and the API Operation Description.
• Tags and Headers
  • How you can easily document your API operations without requiring the traditional Word/PDF documents that can quickly become deprecated and obsolete. We will address the use of Tags and Headers

Where I can download it

You can download the whitepaper here:

I hope you enjoy reading this paper and any comments or suggestions are welcome.

Author: Sandro Pereira

Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira