Today, let's look at a premium trigger, but not just any trigger. One of the most useful in my opinion.

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:

Please be careful when searching because it's tempting to pick "HTTP" but this is something entirely different. This is the "HTTP" action, not the trigger that we want to use.

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:

All good.

Other requests

"POST" is the default, but it's not the only option. If you expand the Advanced options of the trigger, you'll find a Method dropdown where you can pick GET, PUT, PATCH, or DELETE instead. This is handy when you want your Flow to behave like a proper REST endpoint - for example, a GET that returns data without accepting a body.

If you want to read more about the HTTP methods themselves, here's a good article that explains everything based on the specification.

Who can trigger the flow?

This is super important and if you're not careful you can get into all types of trouble. When you create the trigger, you'll find a "Who can trigger the flow?" setting with three options:

• Any user in my tenant - the default for new flows. Anyone signed in to your Microsoft 365 tenant can call it, and the request needs a valid Azure AD bearer token in the Authorization header. This is the safe default for internal automations.
• Specific users in my tenant - same as above, but you whitelist specific email addresses. Use this when only a handful of people or service accounts should be allowed to call the Flow.
• Anyone - the classic behavior. The URL contains a SAS token (the long sig=... at the end), and anyone with the full URL can trigger the Flow. Use this only when you truly need an anonymous endpoint, like a public webhook from a service that can't authenticate against Azure AD.

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.

Non-intuitive behaviors

Resetting the URL (regenerating the SAS key)

Microsoft includes in the end of the url the ?sig that will have a random key that will validate that it's you. It's not safe but at least its a way to allow people not the guess the Flow's URL and then start trying to break your Flows.

The frustrating bit is that there's no button for it anywhere in the Power Automate UI. You have to send a small JavaScript command from your browser's developer tools. It sounds scarier than it is, so let me walk you through it.

Step 1: Note the current SAS signature

1. Open your Flow in the Power Automate designer.
2. Open the "When an HTTP request is received" trigger and copy the URL.
3. Make a note of the value after sig=. You'll use it at the end to confirm the new key is actually different.

Step 2: Capture the authorization token from the browser

1. Go to the Flow's Details page (not the designer).
2. Open your browser's developer tools (F12 in Edge or Chrome).
3. Switch to the Network tab.
4. Clear the network log (Ctrl+L) and start recording (Ctrl+E).
5. Refresh the page (Ctrl+R).
6. Filter the requests for api.flow and look for one that starts with runs?api-version=.
7. Click that request. On the Headers subtab:
   • Copy the full Request URL.
   • Copy the Authorization header (careful to only select the Authorization line, not the next header).

Step 3: Build and execute the regenerate request

Take the Request URL you copied and replace the word runs with regenerateAccessKey. Then open the Console tab in developer tools and paste this:

fetch('<regenerateAccessKeyUrl>', {
  method: 'POST',
  headers: {
    'Content-type': 'application/json; charset=UTF-8',
    'Authorization': '<AuthorizationHeader>'
  }
})
.then(result => result.json())
.then(console.log)

Replace <regenerateAccessKeyUrl> with the URL you just built, and <AuthorizationHeader> with the Authorization header you copied. Hit Enter.

Step 4: Verify

Go back to the Flow in the designer and open the trigger. The sig= value should now be different from what you noted in Step 1. That's it - the old URL is dead, the new one is live.

For the full official walkthrough with screenshots, Microsoft has a dedicated page on regenerating the SAS key.

Limitations

There are a few things to keep in mind before you build your integration around this trigger.

The 120-second response timeout

If your Flow needs to return data to the caller (using a "Response" action), it has to reach that Response action within 120 seconds. Anything longer and the caller gets a ResponseTimeout error. The Flow itself keeps running in the background, but the HTTP caller has already walked away.

If you can't guarantee a quick response, use an asynchronous pattern: return a 202 Accepted immediately with a job ID, and let the caller poll for the result (or push it somewhere the caller can pick up later).

Payload size

The overall request payload has to stay under roughly 100 MB. We consider the payload everything that we send to the "HTTP" trigger. That's generous for most JSON, but if you're passing files or base64-encoded images, you'll hit it faster than you'd expect. For large files, upload them somewhere (SharePoint, OneDrive, Blob Storage) and pass a reference in the JSON instead, so that you can use an action like "Get File contents" for example to get the file, if possible of course. This way the Flow will trigger faster and then you can use the proper action to fetch the file, avoiding issues in the process.

URL exposure (Anyone mode)

When you use the "Anyone" authentication mode, the URL is the security. Here's an example of what one looks like (values are random, of course).

https://prod-00.westeurope.logic.azure.com:443/workflows/00000000000000000000000000000000/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

If this URL ends up in a Git repository, a chat message, or a browser history on a shared machine, anyone who sees it can run your Flow. The good news is that you can regenerate the SAS key to kill the old URL - the bad news is that it's not a one-click operation. See Resetting the URL above for the full process, and keep it in your back pocket for the day something leaks.

Premium connector

Last but not least, this is a premium trigger. You'll need a Power Automate Premium license to use it. It's worth mentioning because it's easy to build a prototype with it and then realize it won't run for the rest of your team.

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.

Default to tenant authentication

Unless you specifically need an anonymous endpoint, pick "Any user in my tenant" or "Specific users in my tenant" when creating the trigger. It's the single easiest thing you can do to stop a leaked URL from turning into an incident. Only switch to Anyone when a non-Microsoft system on the other end literally cannot send an Azure AD bearer token.

Practice the SAS key reset before you need it

If you're using Anyone mode, the day the URL leaks is the worst possible day to learn the reset process for the first time. It's not a button - it's a browser dev-tools dance (see Resetting the URL). Do a dry run on a test Flow now, bookmark the Microsoft docs, and add the steps to your incident response checklist. Future-you will be grateful.

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.

Final Thoughts

The "When an HTTP request is received" trigger opens Power Automate to the outside world, turning your flows into tiny web services you can call from anywhere. Just remember to guard that URL - anyone with it can run your flow. Pair it with a well-defined JSON Schema and you have a flexible, reusable building block.

Back to the Power Automate Trigger Reference.

Photo by Ibrahim Rifath on Unsplash