Almanac
Microsoft/power-automatePower Platform

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

power-automate/03-connectors-and-integration/feature-http-and-webhook-actions.md
feature-http-and-webhook-actions.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn ↗

What it does

The HTTP action calls any REST endpoint from inside a flow, and the When an HTTP request is received trigger turns a flow into an endpoint that other systems can call. Together they're the escape hatch for anything without a connector, and the standard way to make a flow the receiving end of someone else's webhook.

Key facts

  • The HTTP connectors are premium class in Power Automate and Power Apps. The plain HTTP connector supports gateway-based auth for internal endpoints; HTTP with Microsoft Entra ID (preauthorized) covers Entra-authenticated services.
  • The HTTP request trigger has three authentication modes: Any user in my tenant (the default for new flows), Specific users in my tenant, and Anyone — the legacy open-access setting.
  • Set Specific users in my tenant and leave the allowed users list empty and the scope quietly falls back to the whole tenant. Enter email addresses, or object IDs for service principals.
  • Authenticated callers must present the right claims: aud matching the flow service audience for the cloud (https://service.flow.microsoft.com/ for public cloud, different values for GCC, GCC High, China and DoD), plus iss and tid, and oid when the trigger is restricted to specific users.
  • The trigger URL carries a shared access signature in the sig= parameter. Regenerating the SAS key invalidates the old URL, so every caller has to be updated.
  • HTTP with Microsoft Entra ID base64-encodes the request body and doesn't handle raw binary — files come back corrupted. It also caps at 100 API calls per connection per 60 seconds.

When to use / skip

Use HTTP when there's genuinely no connector, when you need control over headers and payload that a connector won't give you, or when you're integrating with an internal API through the gateway. Use the HTTP request trigger when an external system needs to push work into Power Automate and can't be polled. Skip raw HTTP if you're calling the same API from three or more flows — that's a custom connector, and doing it as HTTP means the auth and the URL are copy-pasted in three places waiting to drift.

Configuration decisions

  • Webhook push versus polling trigger: push gives you near-real-time and no wasted runs, polling is simpler to secure and survives the caller not being able to do outbound HTTPS.
  • Which authentication mode the HTTP request trigger uses, and whether callers are named users, service principals, or genuinely anonymous.
  • Whether the endpoint sits behind the tenant IP firewall so only allowed source addresses can reach it.
  • Where secrets for outbound HTTP calls live — Azure Key Vault via connector, environment variables, or hardcoded in the action, which is the wrong answer.
  • Whether the trigger inputs and outputs are marked as secure so payloads don't sit in plain text in run history.

Gotchas

  • "Anyone" endpoints are open on the public internet to whoever holds the URL. The URL leaks through documentation, Postman collections, browser history and support tickets, and there's no rate limit protecting you.
  • The SAS key in the trigger URL is a bearer credential. Anyone who can read the flow definition can call the endpoint.
  • Regenerating the SAS key breaks every caller immediately. Plan it as a coordinated change, not a security tidy-up on a Friday.
  • The HTTP request trigger returns 202 by default and the caller gets nothing useful back unless you add a Response action — and Response has to be reached within the synchronous timeout or the caller times out while the flow carries on.
  • Failed HTTP calls return the response body into run history. Bearer tokens and API keys in error responses end up visible to anyone with run history access.

Consultant notes

  • Treat any flow with an HTTP request trigger as a published API and get it into the client's API inventory and security review. It usually isn't, and that's the finding.
  • The auth conversation is with the calling system's owner, not the Power Platform team. Book it early — service principal object IDs take longer to get than you'd think.
  • Warn the client that HTTP actions bypass DLP classification of the target service. A flow calling a blocked SaaS product's REST API directly is a governance gap that DLP policies won't catch.

Recheck the trigger authentication modes and audience values after each release wave — this area has moved twice recently

Was this accurate?
Related
Custom connectors03-connectors-and-integrationCloud flow types and triggers01-cloud-flowsCloud flow vs desktop flow11-decision-guidesAPI request limits09-licensing-and-capacityConnections, authentication and OAuth03-connectors-and-integrationCommon failure patterns10-monitoring-and-troubleshooting