Friday Fact: When a HTTP Request is Received trigger can accept more http methods other than POST

Diving into Logic Apps, it’s a common oversight to assume that only POST requests can be use when using the “When a HTTP request is received” trigger. However, the beauty of this feature is its support for the full spectrum of HTTP methods, nudging us towards adopting REST API best practices right in our Logic Apps designs. Remember, the action your Logic App takes should align with the HTTP request method you opt for—whether that’s GET to fetch data, POST to add new info, PUT or PATCH to update existing data, or DELETE to remove it.

To seamlessly integrate different HTTP methods into your Logic App workflows, follow these straightforward steps. Begin by selecting “Add new parameter” in the “When a HTTP request is received” trigger settings.

Then, choose the “Method” parameter.

This action unveils a variety of HTTP methods at your disposal, including GET, PUT, POST, PATCH, and DELETE, empowering you to design more versatile and effective applications.

This means that now your Logic App will only be triggered by the respective method you have choosen.

But you can also integrate URI parameters within your methods, let’s use the HTTP GET method as an example, this enhances both functionality and flexibility of your Logic Apps. Here’s a streamlined approach to configure it:

Navigate to “When a HTTP request is received” trigger, select “Add new parameter,” and then choose “Relative Path.”

Input your URI pattern, for example: /firstname/{fname}/lastname/{lname}, defining two parameters: fname and lname.

Save your Logic app, and you will notice that your trigger URI changed to include the Relative Path content.

Using these steps will automatically tokenize the parameters added in the Relative Path, seamlessly integrating them into your Logic App’s workflow.

Accessing these tokenized values in subsequent actions is straightforward. They appear as tokens within the dynamic content selection, ready to be incorporated into your Logic App’s logic with precision and ease.

This method ensures your Logic Apps are not only more dynamic but also professionally structured for enhanced data handling.

Also you can use one of our previous Friday Fact tips and apply a Trigger condition:

Incorporating trigger conditions into your Logic Apps can significantly enhance security and specificity in your workflows. A practical example is applying a condition based on a query parameter:

@equals(triggerOutputs()['queries']['path'], 'MyProjectName')

This condition checks if the path query parameter matches ‘MyProjectName‘.

To refine your Logic App’s accessibility, simply append this condition to your trigger.

By doing so, your Logic App will only respond to URLs containing the specified query, ensuring that it operates under a more controlled and secure environment.


This approach is particularly useful for ensuring that only involved personnel can interact with your Logic App, regardless of the HTTP method used. Applying such conditions to your projects can serve as a robust layer of security, safeguarding your workflows and maintaining operational integrity.

Stay tuned for more content like this! See you next Friday with another Friday Fact!

To lazy to read? We’ve got you covered! Check out our video version of this content!

Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Star Wars Lego for Sandro’s son!

Happy automating!

Author: Luis Rigueira

Luis Rigueira is a Enterprise Integration Consultant at DevScope

Leave a Reply

Your email address will not be published. Required fields are marked *


Back to Top