Today a premium connector. The “When an HTTP request is received” trigger is special because 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. In my “Power Automate as a Webservice” article, I wrote about this in the past, 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 massive 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 pretty 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 the following:
{
"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, 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. We’ll need to provide an array with two 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 array rows. If you make them different, like this:
[
{
"parameter1":"string parameter",
"parameter2":1,
"parameter3":false
},
{
"parameter4":"string parameter",
"parameter5":1,
"parameter6":false
}
]
You’ll get the following:
{
"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 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 the following:
{
"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 expect with the Schema. Anything else won’t be taken because it’s not what we need to proceed with.
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. It’s a lot easier to generate a JSON with what you need.
Name it correctly
The name is super important 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 your expectations, why the Flow should be triggered, and the data used. Again, it’s essential to enable faster debugging when something goes wrong.
Back to the Power Automate Trigger Reference.
Photo by Ibrahim Rifath on Unsplash
Hi Manuel,
Do you know where I can programmatically retrieve the flow URL. I need to create some environmental variables for devops so I can update the webhook in the Power Platform as we import it into other environments.
Hi Mark,
It’s a good question, but I don’t think it’s possible, at least not that I’m aware of.
If someone else knows this, it would be great.
Thanks!
Thank you for When an HTTP request is received Trigger. We have created a flow using this trigger, and call it via a hyperlink embedded in an email. Clicking the sends a GET request to the trigger’s URL and the flow executes correctly, which is all good. However, because we’ve sent the GET request to the flow, the flow returns a blank html page, which loads into our default browser.
We want to suppress or otherwise avoid the blank HTML page. POST is not an option, because we’re using a simply HTML anchor tag to call our flow; no JavaScript available in this model.
Does the trigger include any features to skip the RESPONSE for our GET request? In a perfect world, our “click” will run the flow, but open no browsers and display no html pages.
Advice?
You’re welcome :).
Your reasoning is correct, but I don’t think it’s possible. My first thought was Javascript as well, but I wonder if it would work due to the “authentication” process necessary to certify that you have access to the Flow. I’m not sure how well Microsoft deals with requests in this case.
I can’t find a suitable solution on the top of my mind sorry 🙁
Any advice on what to do when you have the same property name? For instance, you have an object with child objects, and each child object has an ‘id’. how do I know which id is the right one?
Hi Luis,
I don’t think it’s possible. Power Automate will consider them the same since the “id” is the “key” of the object, and the key needs to be unique to reference it.
When you try to generate the schema, Power Automate will generate it with only one value. For example:
{
"id":1,
"id":2
}
will result in:
{
"type": "object",
"properties": {
"id": {
"type": "integer"
}
}
}
Having nested “id” keys is ok since you can reference it as triggerBody()?[‘id’]?[‘id’] for example
Cheers
Manuel
I’d like to validate requests that are received using the schema. I’ve gone into settings and turned that feature on. Yet when I make a request it still seems to accept it and return a 202 response. My schema uses an enum for one of the properties to list acceptable values for that particular property. I’m pretty limited in my understanding of schemas. But Power Automate does not seem to enforce any limited set of values for that property with my current setup. Any ideas?
Hi,
If an outlook email needs to be trigged after the http request is received, with the body of the email having the request payload OR just the parameters and their values then how can that be achieved?
Thanks.
can this trigger be used to receive multiple parameters and a file (or for example a parameter with “file name” and “file content” )?
I want to implement this but dont know if it is possible and how the new JSON schema would look like.
Any thoughts?
Hi ,
with this when a HTTP request recieved trigger the POST URL is changing when I open the flow in edit mode ..and saying “URL will generate on Save” ,but I want to retain the old one always because of this issue I can’t modify the flow much … how can I avoid this issue …Please reply.
Hi I’d like to trigger a power automate flow from a powershell script in my release dev ops pipeline. Would it make more sense to use a json file like your example as i don’t any data from the pipeline but i’m guessing i need to put some dummy data in to trigger the flow?