When working with Azure Logic Apps, many developers assume that the When a HTTP request is received trigger supports only POST requests. However, this assumption is incorrect. The trigger supports the full range of HTTP methods, which encourages better adherence to REST API best practices.
For this reason, the action your Logic App performs should match the chosen HTTP method. Use GET to retrieve data, POST to create new resources, PUT or PATCH to update existing ones, and DELETE to remove them.
📝 One-Minute Brief
Many developers assume that the “When a HTTP request is received” trigger in Azure Logic Apps only supports POST requests. However, this Friday Fact explains how the trigger can accept multiple HTTP methods, such as GET, PUT, PATCH, and DELETE. Understanding this capability allows you to design Logic Apps that better follow REST principles and build more flexible, API‑driven workflows.
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 chosen.
You can also integrate URI parameters within your methods to increase flexibility. For example, using the HTTP GET method allows you to pass values directly through the request path, which enhances both functionality and clarity in your Logic Apps.
Here’s a streamlined approach to configure this scenario:
- 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.
These steps automatically tokenize the parameters defined in the Relative Path, which integrates them directly into your Logic App workflow.
You can then access these tokenized values in subsequent actions with ease. They appear as dynamic content tokens, ready to use in your Logic App logic with precision and consistency.
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.
&path=MyProjectName
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!
