by Today a premium connector. “When an HTTP request is received” trigger is special in the sense that it enables us to have Power Automate as a service. What I mean by this is that you can have Flows that are called outside Power Automate, and since it’s using standards, we can use many tools to do it. I wrote about this in the past in my “Power Automate as a Webservice” article, in case you’re interested.
So let’s explore the “When an HTTP request is received” trigger and see what we can do with it.
Where to find it?
To find it, you can search for “When an HTTP request is received.”
It looks like this:
Usage
To use it, we have to define the JSON Schema. I go into huge detail in the “What is a JSON Schema” article, but you need to understand that the trigger expects a JSON to be provided with all parameters. JSON can be quite complex, so I recommend the following. Use the “Use sample payload to generate schema” to help you do this.
Here are some examples to get you started. In this case, we’ll provide a string, integer, and boolean.
{
"parameter1":"string parameter",
"parameter2":1,
"parameter3":false
}
Copy it to the “Use sample payload to generate schema.”
It will generate:
{
"type": "object",
"properties": {
"parameter1": {
"type": "string"
},
"parameter2": {
"type": "integer"
},
"parameter3": {
"type": "boolean"
}
}
}
The properties need to have the name that you want to call them. For example, above, I’ll call for “parameter1” when I want the string. But the value doesn’t need to make sense. Power Automate will look at the type of value and not the content.
Let’s look at another. In this case, we’ll expect multiple values of the previous items. To do it, we’ll need to provide an array with 2 or more objects so that Power Automate knows it’s an array. Here’s an example:
[
{
"parameter1":"string parameter",
"parameter2":1,
"parameter3":false
},
{
"parameter1":"string parameter",
"parameter2":1,
"parameter3":false
}
]
We get:
{
"type": "array",
"items": {
"type": "object",
"properties": {
"parameter1": {
"type": "string"
},
"parameter2": {
"type": "integer"
},
"parameter3": {
"type": "boolean"
}
},
"required": [
"parameter1",
"parameter2",
"parameter3"
]
}
}
Please note that the properties are the same in both rows of the array. If you make them different, like this:
[
{
"parameter1":"string parameter",
"parameter2":1,
"parameter3":false
},
{
"parameter4":"string parameter",
"parameter5":1,
"parameter6":false
}
]
You’ll get:
{
"type": "array",
"items": {
"type": "object",
"properties": {
"parameter1": {
"type": "string"
},
"parameter2": {
"type": "integer"
},
"parameter3": {
"type": "boolean"
},
"parameter4": {
"type": "string"
},
"parameter5": {
"type": "integer"
},
"parameter6": {
"type": "boolean"
}
},
"required": []
}
}
Since the properties are different, none of them is required.
Trigger the Flow
There are a lot of ways to trigger the Flow, including online.
To test, we’ll use the iOS Shortcuts app to show you that it’s possible even on mobile. We’ll provide the following JSON:
{
"parameter1":"string parameter",
"parameter2":1,
"parameter3":false
}
Here’s the template.
We get on Power Automate:
Shortcuts do a lot of work for us so let’s try Postman to have a “raw” request.
All good.
Other requests
If you notice on the top of the trigger, you’ll see that it mentions “POST.”
“POST” is a type of request, but there are others. I won’t go into too much detail here, but if you want to read more about it, here’s a good article that explains everything based on the specification.
Child Flow
Power Automate allows you to use a Flow with a “When an HTTP request is received” trigger as a child Flow. Then, you can call it, and it will even recognize the parameters.
It works exactly like the same way as the “Manually trigger a Flow” trigger, but you need to include at the end of the child Flow a “Respond to a PowerApp or Flow “ action or a “Response” action so that the parent knows when the child Flow ended.
Outputs
The trigger returns the information that we defined in the JSON Schema. So, for the examples above, we get:
{
"headers": {
"Connection": "keep-alive",
"Accept": "*/*",
"Accept-Encoding": "br,gzip,deflate",
"Host": "prod.westeurope.logic.azure.com:443",
"User-Agent": "PostmanRuntime/7.28.4",
"Postman-Token": "2b636af8-62a5-4ff7-b160-cb06ad59f510",
"Content-Length": "80",
"Content-Type": "application/json"
},
"body": {
"parameter1": "string parameter",
"parameter2": 1,
"parameter3": false
}
}
Since the “When an HTTP request is received” trigger can accept anything in a JSON format, we need to define what we’re expecting with the Schema. Anything else won’t be accepted because it’s not what we need to proceed.
Limitations
For some, it’s an issue that there’s no authentication for the Flow. However, if someone has Flow’s URL, they can run it since Microsoft trusts that you won’t disclose its full URL.
Here’s an example of the URL (values are random, of course).
https://prod-121.westeurope.logic.azure.com:443/workflows/1a0340b17abc499a9a16c1779fe5c749/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=nyDHvV9Y5PKteCu4xAQVlixGtvXhalZ80Ti3Yz1BF4V5rpqWl8uUYn8VcwRz
So please keep your Flows private and secure.
Recommendations
Here are some things to keep in mind.
Don’t generate the schema.
There’s no great need to generate the schema by hand. It’s tricky, and you can make mistakes. Instead, always provide a JSON and let Power Automate generate the schema for you. It’s a lot easier to generate a JSON with what you need.
Name it correctly
The name is super important in this case since we can get the trigger from anywhere and with anything. Always build the name so that other people can understand what you are using without opening the action and checking the details.
Always add a comment.
Adding a comment will also help to avoid mistakes. Indicate what you’re expecting, why the Flow should be triggered, and the data used. Again, it’s important to enable faster debugging when something goes wrong.
Back to the Power Automate Trigger Reference.
Photo by Ibrahim Rifath on Unsplash
