Power Automate HTTP Request Trigger: Build Webhooks Without Code

What the HTTP Request Trigger Actually Does

The When a HTTP request is received trigger is one of the most powerful and underused features in Power Automate. It turns any flow into a publicly accessible REST endpoint — no Azure Functions, no Azure API Management, no custom code required. Any system that can make an HTTP POST request (your SPFx web part, a Python script, a Shopify webhook, a GitHub Action) can instantly trigger a complex multi-step workflow that spans SharePoint, Teams, Outlook, SQL, and hundreds of other connectors.

When you add the trigger to a flow, Power Automate generates a unique HTTPS URL. The URL contains a Shared Access Signature (SAS) token embedded in the query string, which acts as the authentication mechanism. Anyone who holds that URL can trigger your flow, which means you must treat it like a secret key. Microsoft's recommendation is to store the URL in an Azure Key Vault secret and retrieve it at call time rather than hardcoding it in your SPFx solution or external application.

The trigger supports HTTP POST by default, but you can also configure it to accept GET, PUT, PATCH, or DELETE by setting the method field in the trigger's advanced options. In practice, POST covers the vast majority of webhook scenarios — you send a payload in the request body, the flow processes it, and optionally returns a response. The ability to return a synchronous HTTP response from the flow using the Response action is what makes this trigger truly useful as an API endpoint rather than just a fire-and-forget webhook receiver.

Creating the Endpoint: Step-by-Step Flow Setup

Creating an HTTP-triggered flow takes under five minutes if you know where to go. In Power Automate, create a new Automated Cloud Flow, search for "HTTP" in the trigger picker, and select "When a HTTP request is received". Save the flow immediately — Power Automate generates the endpoint URL only after the first save. Copy that URL to a safe location before proceeding.

The trigger has one critical configuration field: the JSON schema for the expected request body. While the schema is technically optional, defining it is non-negotiable in any production flow because it is what makes body fields available as dynamic content tokens in subsequent actions. Without a schema, the entire request body arrives as a single opaque string and you must parse it manually with the json() expression, which is error-prone and unreadable.

{
  "employeeId": "EMP-1042",
  "employeeName": "Priya Sharma",
  "leaveType": "Annual",
  "startDate": "2025-07-14",
  "endDate": "2025-07-18",
  "days": 5,
  "reason": "Family vacation",
  "managerId": "[email protected]"
}

Once you have a sample body, use the Use sample payload to generate schema button inside the trigger configuration. Paste your sample JSON and Power Automate generates the full JSON Schema definition automatically, inferring types from the sample values. You can then edit the schema to make fields optional, add descriptions, or add enum constraints — all of which improve validation and make the dynamic content tokens self-documenting for other flow authors.

JSON Schema Definition: Validation and Dynamic Tokens

Understanding the JSON Schema that Power Automate stores in the trigger helps you build more robust flows. The schema tells the runtime two things: how to parse the incoming request body, and which field names to expose as tokens in the dynamic content panel. Fields that appear in the schema but are missing from the actual request body will resolve to null rather than causing the flow to fail — which is useful for optional fields but can mask bugs if you are not careful.

{
  "type": "object",
  "properties": {
    "employeeId":   { "type": "string", "description": "HR system employee ID" },
    "employeeName": { "type": "string" },
    "leaveType":    { "type": "string", "enum": ["Annual", "Sick", "Casual", "Maternity"] },
    "startDate":    { "type": "string", "format": "date" },
    "endDate":      { "type": "string", "format": "date" },
    "days":         { "type": "integer", "minimum": 1, "maximum": 90 },
    "reason":       { "type": "string" },
    "managerId":    { "type": "string", "format": "email" }
  },
  "required": ["employeeId", "leaveType", "startDate", "endDate", "days", "managerId"]
}

Note that Power Automate's runtime does not enforce the required array at the HTTP level — it does not return a 400 if a required field is absent. The schema is for documentation and token generation only. If you need true input validation, add a Condition action immediately after the trigger that checks for empty required fields and returns a 400 response if validation fails. This keeps your flow predictable and makes integration errors obvious to callers.

Authentication: SAS Tokens, Azure AD, and API Keys

The SAS token in the generated URL is Power Automate's default authentication mechanism. It is a time-limited, URL-safe token that Microsoft rotates when you save a new version of the flow. The URL itself should be treated as a secret — anyone who has it can call the flow without any further authentication. This level of security is acceptable for internal Microsoft 365 integrations where the URL is stored in SharePoint or Key Vault, but insufficient for public-facing webhooks from external systems.

For stronger security, enable Azure Active Directory OAuth on the trigger. This replaces the SAS token with a proper OAuth bearer token requirement. The caller must first obtain a token from Azure AD using a registered app's client credentials and then pass it in the Authorization: Bearer <token> header. This approach is ideal when calling the flow from a backend service, an Azure Function, or any system that can perform the OAuth client credentials flow.

# Register an app in Azure AD with the correct resource scope first
$body = @{
  grant_type    = 'client_credentials'
  client_id     = '<your-app-client-id>'
  client_secret = '<your-app-client-secret>'
  scope         = 'https://service.flow.microsoft.com/.default'
}
$token = (Invoke-RestMethod -Uri "https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token" `
  -Method POST -Body $body).access_token

# Call the Power Automate HTTP trigger with the bearer token
$payload = @{
  employeeId   = 'EMP-1042'
  leaveType    = 'Annual'
  startDate    = '2025-07-14'
  endDate      = '2025-07-18'
  days         = 5
  managerId    = '[email protected]'
} | ConvertTo-Json

Invoke-RestMethod -Uri '<your-flow-http-url>' `
  -Method POST `
  -Headers @{ Authorization = "Bearer $token"; 'Content-Type' = 'application/json' } `
  -Body $payload

Calling the Flow Endpoint from an SPFx Web Part

Calling a Power Automate HTTP trigger from an SPFx web part requires care because browsers enforce CORS. The good news is that Power Automate's HTTP trigger URLs return a Access-Control-Allow-Origin: * header, which means direct browser calls work without a proxy — one of the few cloud services that does this reliably. You can call the flow URL directly from your useEffect hook using the browser's native fetch API or via the SPFx HttpClient.

import { HttpClient, IHttpClientOptions } from '@microsoft/sp-http';

const submitLeaveRequest = async (
  httpClient: HttpClient,
  flowUrl: string,
  payload: ILeaveRequest
): Promise<{ status: string; itemId: number }> => {
  const options: IHttpClientOptions = {
    body: JSON.stringify(payload),
    headers: {
      'Content-Type': 'application/json',
      'Accept': 'application/json',
    },
  };

  const response = await httpClient.post(
    flowUrl,
    HttpClient.configurations.v1,
    options
  );

  if (!response.ok) {
    const errBody = await response.text();
    throw new Error(`Flow returned ${response.status}: ${errBody}`);
  }

  return response.json(); // The Response action in the flow sends this back
};

Store the flow URL in the web part's property pane as a configurable string field rather than hardcoding it. This allows IT admins to update the flow URL (which changes when the flow is re-saved with breaking changes) without requiring a new web part deployment. An even cleaner approach is to store the URL in a SharePoint list item and fetch it at runtime — the web part then always calls the latest flow URL without any property pane reconfiguration.

Error Handling: Validation Responses and Retry Logic

A production-ready HTTP-triggered flow must handle three failure categories: invalid input (respond with 400), processing errors in the flow itself (respond with 500 and a structured error body), and downstream service failures like SharePoint throttling (retry internally before responding). The Response action lets you return any HTTP status code and any JSON body, giving you full control over the API contract.

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The 'days' field must be between 1 and 90.",
    "field": "days",
    "receivedValue": "@{triggerBody()?['days']}"
  },
  "requestId": "@{workflow().run.name}"
}

The workflow().run.name expression gives you the unique run ID for the current flow execution. Always include this in error responses — it lets the caller provide the run ID to an admin who can immediately find the failed run in the Power Automate run history without searching through thousands of executions. This single addition dramatically reduces debugging time in production incidents.

Monitoring: Run History, Analytics, and Alerting

Once the flow is in production, monitoring becomes critical. Power Automate's built-in run history shows every execution with its inputs, outputs, duration, and failure reason. Access it by navigating to the flow's detail page and clicking 28 day run history or the specific All runs view. Each run expands to show every action's inputs and outputs, which makes debugging straightforward — you can see exactly which step failed and what the data looked like at that point.

For higher-volume flows, the built-in run history is insufficient because it paginates and does not support filtering or aggregation. In these cases, add a Send an HTTP request to SharePoint action at the end of the flow that logs the run result (status, duration, key fields from the payload) to a SharePoint list. You can then build a Power BI report on top of that list to track success rates, average processing time, and peak call volumes over time.

For alerting, use the Configure run after setting on the final Response action — add a parallel branch that runs only when a previous action fails and sends an email or Teams adaptive card to your ops team. This gives you a basic on-call alerting system without needing any external monitoring infrastructure.

Real-World Examples: Three Production Webhook Patterns

The HTTP trigger shines in three recurring integration scenarios we encounter across enterprise Microsoft 365 projects. Understanding these patterns gives you a template you can adapt for almost any integration requirement.

Pattern 1: SPFx Form to Multi-System Workflow

An SPFx web part hosts a custom leave request form. On submit, the web part calls the Power Automate flow URL with the form payload. The flow creates a SharePoint list item, starts an approval to the manager via Teams Adaptive Card, waits for the approval response, updates the HR system via a custom connector, and returns the final approval status synchronously. The SPFx component shows the manager's decision to the employee immediately after submission.

Pattern 2: External SaaS Webhook Receiver

A Shopify store sends order-created webhooks to the Power Automate endpoint. The flow validates the payload, creates a new record in a SharePoint list used by the warehouse team, sends a Teams channel notification with order details, and returns a 200 to Shopify within the 5-second window Shopify requires. No Azure infrastructure required — the flow handles the entire integration.

Pattern 3: Scheduled ETL Trigger

An on-premises Python ETL script runs nightly, processes a CSV file, and calls the Power Automate endpoint with a batch of rows. The flow uses a Parse JSON action to handle the array, iterates with Apply to Each, and upserts records into SharePoint. A final summary email is sent to the data team. The HTTP trigger eliminates the need for Azure Service Bus or Logic Apps — Power Automate is the middleware.