web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

News and Announcements icon
Community site session details

Community site session details

Session Id :
Power Platform Community / Forums / Power Automate / Power automate cloud -...
Power Automate
Suggested Answer

Power automate cloud - HTTP - Error 302

(0) ShareShare
ReportReport
Posted on by

Hi everyone,

I’m reaching out for help as I’ve hit a wall with my flow and I’m running out of ideas.

Flow Description:
My flow retrieves data from an Excel file, filters it, generates an authorization token, and then creates records in an external application via API (POST method).

The Problem:
The flow was running stably for the first 100+ records. However, it started failing on the last 10 items (please see the attached screenshot for error details). What's strange is:

  • The error occurs randomly across different HTTP actions (sometimes during token generation, other times during the actual POST request).

  • The flow logic seems correct, as the vast majority of records were processed successfully using the exact same schema.

  • I’ve already tried adding a 5-minute delay before each HTTP action inside the "Apply to each" loop, but unfortunately, it didn't solve the issue.

I would really appreciate any suggestions on what might be causing this or how to debug it further. Thanks in advance!

111.png
2222.png
Categories:
I have the same question (0)
  • Suggested answer
    MParikh Profile Picture
    521 Super User 2026 Season 1 on at

    Your screenshots show HTTP 502 with an AWS ALB header. That points to an upstream issue. Power Automate reached the load balancer, then the load balancer did not get a valid response from the backend. Content-Length 0 is another hint. This is rarely a schema problem in the flow itself.
    Still, there are a few Power Automate patterns that trigger this near the end of a long run.

    1. Remove parallelism inside Apply to each
      If concurrency is enabled, calls overlap. Some APIs start failing under burst load, and it looks “random” across actions.
    • Open Apply to each
    • Settings
    • Concurrency control On
    • Degree of parallelism = 1
    1. Stop generating a token per item
      Token endpoints often rate-limit. If token generation runs inside the loop, you hammer auth plus POST endpoints.
      Better pattern
    • Generate token once before the loop
    • Store token in a variable
    • Use it for all POST calls
    • If a POST returns 401, refresh token once, then retry that item
    1. Add a real retry policy, not a fixed 5-minute delay
      A static delay before every request does not help when the failure is transient. Retries need backoff and jitter.
      For each HTTP action (token + POST):
    • Settings
    • Retry policy = Exponential
    • Count 6 to 8
    • Minimum interval 20 to 30 seconds
    If the connector UI does not expose the retry shape you want, wrap the HTTP in a Scope and implement:
    • Do until Success
    • Delay with increasing intervals: 15s, 30s, 60s, 120s, 240s
    • Exit after N attempts
    1. Reduce payload risk on the last rows
      Last few Excel rows often contain hidden surprises: trailing spaces, nulls, “0.00” stored as text, unexpected booleans, empty required fields. Many APIs should return 400, yet some backends crash and produce 502.
      Add validation before calling HTTP:
    • Guard clauses for required fields
    • Normalize types with explicit conversions
    • Trim strings
    • Replace blanks with null or defaults, based on API contract
      Log the failing item into a “FailedItems” array with row number plus payload snapshot.
    1. Add strong diagnostics in the run history
      You need correlation markers per record, otherwise debugging is blind.
      Add a Compose before each HTTP with:
    • Row identifier
    • Endpoint name
    • Payload hash or key fields
      Then after each HTTP, store:
    • statusCode
    • headers
    • body
      Write these to a log table, SharePoint list, or a single JSON file in OneDrive.
    1. Protect the external API with pacing, not blanket delay
      If the backend has a rate limit, pace requests per item:
    • Delay 2 to 5 seconds after each successful POST
    • Keep exponential retry for failures
      This reduces sustained load while still finishing the batch.
    1. Make POST idempotent
      If retries run, duplicates become a risk.
      Use a stable externalId from Excel (or generate one) and send it in the payload. The API should treat repeated requests as update or ignore.
    A quick test to prove root cause
    Run the flow for only the last 10 rows.
    • If failures continue, the issue ties to those records or API stability.
    • If failures vanish, the issue ties to load, throttling, token churn, or long-run backend state.

    Thank you! 
    Proud to be a Super User!
    📩 Need more help?
    ✔️ Don’t forget to Accept as Solution if this guidance worked for you.
    💛 Your Like motivates me to keep helping

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Season of Sharing Community Challenge Launch!

Jump in, show your community spirit, and win prizes!

Kudos to our 2025 Community Spotlight Honorees

Expanding mentorship, skilling, and AI innovation

Congratulations to the May Top 10 Community Leaders!

These are the community rock stars!

Leaderboard > Power Automate

#1
Valantis Profile Picture

Valantis 377

#2
11manish Profile Picture

11manish 279

#3
David_MA Profile Picture

David_MA 234 Super User 2026 Season 1

Last 30 days Overall leaderboard