Dealing with HTTP 302 in Logic Apps

In this post, I’ll be talking about how to handle HTTP 302 status code in Logic Apps.

I received a simple request from a client where he wanted to call an API that was returning a CSV document so it could be stored in an Azure blob storage.

Since we all know how easy it is to consume API’s from Logic Apps, I imagined that this one was going to be no big deal as well.

Creating the Logic App

With that mindset I created the Logic App and configured the HTTP request passing the URL and all the parameters needed to consume the API as below:

As you can see, a very straightforward configuration using the HTTP connector. But then, when executed I received the following HTTP 302 status code that Logic Apps understood as an error:

Looking at documentation about 302 (https://en.wikipedia.org/wiki/HTTP_302), I realized the Logic App should be receiving back a Location header indicating where the resource I needed was, and as you can see in the picture above, that information was being returned.

But since Logic App understood that HTTP 302 response as an error I had to configure the Run After to handle both successful responses and error responses.

With this done, then I could make a second call using this time the Location header returned from the first call.

This time with the redirection URL Logic App was able to retrieve the CSV file it need and then I could complete the rest of the integration logic and send this file to a blob storage.

Summary

A simple solution to overcome the handling of HTTP 302 as error by Logic App. Maybe an improvement for Logic Apps would be to understand better that not all HTTP status codes are errors, so we could have a better configuration of the Run After instead of doing a catch of these other HTTP responses as errors.

Alessandro Moura

Certified BizTalk, Mulesoft, TOGAF and Azure. Integration Specialist. Solutions Architect.

Leave a Reply

%d bloggers like this: