HTTP Requests & APIs

The HTTP action

The HTTP action sends a raw request to any reachable endpoint. It is a premium connector, so every user who runs the flow needs a Power Automate premium license (or the flow runs in a Process/per-flow plan). For Microsoft 365 data, prefer the first-party connectors (Graph via Office 365 Groups, SharePoint, etc.) before reaching for raw HTTP.

Authentication

Client-credentials OAuth (app-only)

Authority:   https://login.microsoftonline.com
Tenant:      <tenant-id>
Audience:    https://graph.microsoft.com
Client ID:   <app-registration-client-id>
Credential:  Secret
Secret:      @{parameters('GraphClientSecret')}   // from an environment variable

Auth deep-dive: Key Vault, Managed Identity, certificates, SAS

Production auth means getting secrets out of the flow body entirely. Prefer a workload identity (Managed Identity) where the target accepts Azure AD tokens; fall back to a secret or certificate that lives in Azure Key Vault, never in an action.

Azure Key Vault

1. Store the secret in Key Vault (e.g. GraphClientSecret).
2. Grant the identity that resolves it Get on secrets — an access policy or the Key Vault Secrets User RBAC role.
3. Create a Dataverse environment variable of type *Secret* that points at the Key Vault secret. The value is resolved at runtime and is never stored in the solution.
4. Reference it as @{parameters('GraphClientSecret (secret)')}, or fetch it on demand with the Azure Key Vault → Get secret action.

Managed Identity

Set Authentication = Managed Identity on the HTTP action and supply the Audience of the resource you are calling (e.g. https://graph.microsoft.com, https://vault.azure.net, https://<account>.blob.core.windows.net). Grant the identity an Azure RBAC role on the target (e.g. Key Vault Secrets User, Storage Blob Data Reader). The platform acquires the token — no secret in the flow.

Certificate (client) authentication

Authentication: Active Directory OAuth
Authority:   https://login.microsoftonline.com
Tenant:      <tenant-id>
Audience:    https://graph.microsoft.com
Client ID:   <app-registration-client-id>
Credential:  Certificate
Pfx:         @{parameters('AuthCertPfxBase64')}   // base64 of the .pfx, from Key Vault
Password:    @{parameters('AuthCertPassword')}

SAS tokens (Azure Storage)

For Azure Storage, a Shared Access Signature is appended to the URL as query params — scoped to a resource and time-limited, with no Authorization header. Generate it server-side (or with the Storage connector) and store it in Key Vault rather than minting account keys in the flow.

Calling Microsoft Graph

1. Register an app in Entra ID, add the application Graph permissions you need (e.g. User.Read.All), and grant admin consent.
2. Create a client secret and store it in an environment variable (or pull from Key Vault).
3. In the HTTP action set Authentication = Active Directory OAuth with audience https://graph.microsoft.com.
4. Call the endpoint and Parse JSON the response.

GET https://graph.microsoft.com/v1.0/users?$select=displayName,mail&$top=5
Accept: application/json

Parse JSON

Raw HTTP output is untyped. Add a Parse JSON action, click Generate from sample, paste a real response, and the designer infers a schema so downstream actions get typed dynamic content.

{
  "value": [
    { "id": "1", "displayName": "Ada Lovelace", "mail": "ada@contoso.com" }
  ],
  "@odata.nextLink": "https://graph.microsoft.com/v1.0/users?$skiptoken=..."
}

first(body('Parse_JSON')?['value'])?['displayName']

OData query deep-dive

Graph, SharePoint, and Dataverse all speak OData. Push filtering and shaping into the query string so the API returns only the rows and columns you need — faster, cheaper, and far less likely to be throttled than pulling everything and filtering in the flow.

GET https://graph.microsoft.com/v1.0/users
  ?$filter=accountEnabled eq true and startswith(displayName,'A')
  &$select=displayName,mail,jobTitle
  &$orderby=displayName
  &$top=25

Pagination

Many APIs (Graph included) return a page plus a continuation link. Two options: turn on the action’s built-in Pagination setting (Settings → Pagination → On, set a threshold), or loop manually until the next-link is empty.

Do Until:  empty(variables('nextLink'))
  HTTP GET  variables('nextLink')
  Parse JSON the response
  Append body('Parse_JSON')?['value'] to your results array
  Set variable nextLink = body('Parse_JSON')?['@odata.nextLink']

File handling: uploads, downloads & base64

Binary download

A GET that returns a file gives you a binary body. Pass body('HTTP') straight into a Create file action (SharePoint / OneDrive / Blob). To embed it elsewhere, convert with base64(body('HTTP')).

multipart/form-data upload

Headers:
  Content-Type: multipart/form-data; boundary=----flowlibs

Body:
------flowlibs
Content-Disposition: form-data; name="metadata"
Content-Type: application/json

{ "title": "Q3 report" }
------flowlibs
Content-Disposition: form-data; name="file"; filename="q3.pdf"
Content-Type: application/pdf

@{base64ToBinary(outputs('Get_file_content')?['body'])}
------flowlibs--

base64 in / out

Large files — chunked upload

1. POST to createUploadSession to get a pre-authenticated uploadUrl.
2. PUT each byte range to that URL with a Content-Range: bytes {start}-{end}/{total} header. Every range except the last must be a multiple of 320 KiB (327,680 bytes).
3. The service returns 202 Accepted with nextExpectedRanges between chunks, and the final 200/201 with the created item.

Inbound webhooks (receiving requests)

The When a HTTP request is received trigger (the *Request* built-in connector — no premium) turns a flow into an endpoint. Save the flow once to generate the POST URL; it includes a SAS signature in the sig query parameter, so treat the whole URL as a secret.

Generate the schema from a sample

Click Use sample payload to generate schema, paste a representative JSON body, and the designer builds the JSON Schema — giving you typed trigger outputs to use downstream without a separate Parse JSON.

The Response action

Add a Response action to reply synchronously with a chosen status code, headers, and body. The caller waits for it (up to the request timeout, ~120s). Without a Response action the trigger returns 202 Accepted immediately and the run continues in the background.

Securing the URL

• The URL’s sig token is a credential — store it in an environment variable, never log it, and rotate by regenerating the trigger.
• Require a shared-secret header (e.g. x-webhook-secret) and compare it to an env var in a first Condition; Response 401 and Terminate if it does not match.
• Validate the payload against the generated schema and reject malformed bodies with 400.
• For stronger control, front the endpoint with Azure API Management to add IP allow-listing, rate limits, and signature verification.

Long-running & async patterns

Some APIs accept the work and finish later. They reply 202 Accepted with a Location header that points at a status resource to poll, and often a Retry-After telling you how long to wait.

Poll a 202 + Location

HTTP POST  /jobs            → 202 Accepted
Set variable statusUrl = outputs('HTTP')?['headers']?['Location']

Do Until:  variables('done')
  Delay     <Retry-After seconds, default e.g. 15s>
  HTTP GET  variables('statusUrl')
  Set done = equals(body('HTTP_2')?['status'], 'succeeded')
  (cap the loop count so it cannot run forever)

• Read the redirect target from outputs('HTTP')?['headers']?['Location'].
• Honour Retry-After (seconds, or an HTTP date) for the Delay instead of a fixed sleep.
• Always cap iterations and check for a terminal *failed* status, not just *succeeded*.

Webhook callback pattern

Better than polling: hand the API a callback URL (your *When a HTTP request is received* trigger) and let it call you when the work is done. The built-in HTTP Webhook action formalises this — it subscribes on start, parks the run with no polling cost, and unsubscribes on completion or cancellation.

Throttling: 429, concurrency & batching

APIs push back with 429 Too Many Requests and a Retry-After header. Respect it — retrying immediately just extends the throttle.

• The action’s Default retry policy already honours Retry-After on 408/429/5xx — leave it on for most calls.
• Cap Apply to each concurrency (Settings → Concurrency control) when the loop calls a rate-limited API; high parallelism multiplies your 429s.
• Spread load and cache lookups (a Compose/variable) instead of re-calling per row.

$batch (Microsoft Graph)

Combine up to 20 requests into a single POST to /$batch — fewer round-trips and fewer throttles. Each sub-request returns its own status, so a 429 on one does not fail the batch (the batch itself returns 200). Use dependsOn to sequence; a failed dependency returns 424.

{
  "requests": [
    { "id": "1", "method": "GET", "url": "/me" },
    { "id": "2", "method": "GET", "url": "/me/drive/root/children" },
    { "id": "3", "method": "GET", "url": "/me/messages?$top=5",
      "dependsOn": ["1"] }
  ]
}

Retry, timeout & errors

Network calls fail transiently. By default the HTTP action retries on 408 / 429 / 5xx using the Default policy — an exponential interval, up to 4 retries. Tune it under the action’s Settings.

"retryPolicy": {
  "type": "fixed",
  "interval": "PT30S",
  "count": 2
}

• Set a realistic Timeout (Settings → General → Action Timeout) in ISO 8601, e.g. PT2M. Default single-request timeout is ~100s.
• Wrap the call in a Scope and add a Catch scope configured to run after *has failed / has timed out* (see Best Practices).
• Check the status code explicitly: outputs('HTTP')?['statusCode'] — a 2xx is success, but the action only throws on 4xx/5xx after retries.
• Honour Retry-After headers from APIs that return 429 rather than hammering with your own retries.

Error handling for HTTP

After retries, the action throws on 4xx/5xx. Decide per call: let it fail and catch upstream, or handle inline by reading the status code and branching.

Branch on the status code

Condition: outputs('HTTP')?['statusCode'] is greater than or equal to 400
  If yes → read the error body, log, branch or Terminate
  If no  → continue the happy path

// the status code survives even a "failed" action when you
// set Configure run after → has failed on the next action.

Parse the error body

{
  "error": {
    "code": "Request_ResourceNotFound",
    "message": "Resource '…' does not exist or one of its queried references…"
  }
}

// body('HTTP')?['error']?['message']

Common-API cookbook

Copy-paste starting points for the APIs you reach for most. All assume Authentication = Active Directory OAuth (or Managed Identity) with the right audience; add Content-Type: application/json on writes.

Microsoft Graph

POST https://graph.microsoft.com/v1.0/users/{id}/sendMail
{
  "message": {
    "subject": "Hello",
    "body": { "contentType": "HTML", "content": "<p>Hi</p>" },
    "toRecipients": [{ "emailAddress": { "address": "ada@contoso.com" } }]
  },
  "saveToSentItems": true
}

GET  https://graph.microsoft.com/v1.0/users?$select=displayName,mail&$top=50
GET  https://graph.microsoft.com/v1.0/users/{id}/drive/root/children

SharePoint REST

GET https://contoso.sharepoint.com/sites/Ops/_api/web/lists/getbytitle('Orders')/items?$select=Title,Status&$top=100
Accept: application/json;odata=nometadata

Dataverse Web API

GET  https://org.crm.dynamics.com/api/data/v9.2/accounts?$select=name,telephone1&$top=50
OData-Version: 4.0
OData-MaxVersion: 4.0
Accept: application/json

POST https://org.crm.dynamics.com/api/data/v9.2/accounts
{ "name": "Contoso Ltd", "telephone1": "555-0100" }

Azure DevOps

GET https://dev.azure.com/{org}/{project}/_apis/wit/workitems/{id}?api-version=7.1
Accept: application/json

Generic REST CRUD