Power Automate retries up to 12 times: keep one Sume idempotency key

Power Automate can retry a failed HTTP action up to 12 times over about an hour, and retries count as action runs. Send one Idempotency-Key to Sume.

4 min readSume
All posts

A Power Automate HTTP action that calls a paid API can be retried by the platform: depending on the flow's performance profile the default policy sends up to two retries, or up to twelve spread over about an hour. To keep a Sume job from being created twice, put the same Idempotency-Key header on the submit and make it a value that is identical on every attempt.

Sume's docs say a retry that reuses the same key returns the original job and does not bill a second one, so the retry policy and the key work together.

What Microsoft documents

The numbers below come from Microsoft's limits page. Which performance profile your flow runs under depends on your licence, so check the page and your environment before relying on the larger number.

Power Automate retry and action limits, from Microsoft Learn (read 2026-10-10)
SettingDocumented value
Default retry, Low profileUp to 2 retries at exponentially increasing intervals, last one about 10 minutes out
Default retry, Medium and High profilesUp to 12 retries at exponentially increasing intervals, last one about 1 hour out
Retry attempts (custom policy)90 maximum
Retry minimum delay5 seconds
Retry maximum delay1 day
Action countingSuccessful and failed actions both count toward limits; retries count as action runs

Why a retry is a billing risk

A retry fires when the first attempt looks failed to Power Automate: a timeout, a dropped connection, or a 5xx. The submit may still have reached Sume and created a job. Without a key, each retry is a new paid request. With a key, the second request is recognised.

Build the key from the trigger, not the clock

A key made from utcNow() changes on every attempt and defeats the purpose. Build it from something that identifies the work item, such as the row id or order number from the trigger. The body must stay identical too: Sume's admission docs say a key reused for a different operation or payload returns 409 idempotency_conflict, and the key is meant for an exact retry only.

{
  "method": "POST",
  "uri": "https://api.sume.com/v1/image-1.0/generate",
  "headers": {
    "Authorization": "Bearer @{variables('sumeKey')}",
    "Content-Type": "application/json",
    "Idempotency-Key": "@{concat('pa-order-', triggerOutputs()?['body/ID'])}"
  },
  "body": {
    "prompt": "Product hero shot of a matte black bottle on marble",
    "mode": "async"
  }
}

Pair it with async mode

Send mode async so the submit returns quickly with a job id and status URL, instead of holding the request open. Sume's sync wait is clamped to 30 seconds, which video jobs usually exceed, and the jobs and results page says to continue from the status URL rather than submit again. The same page covers the Idempotency-Key header on submits.

Sume also returns 429 queue_full when a workspace has no accepted capacity left; the generation admission page says to retry later with the same key. That is exactly the case a long retry window handles well.

  • Same key, same body on every attempt.
  • Key derived from the work item, never from the time.
  • Use async or webhook mode for video; poll the status URL after a timeout.
  • Remember retries consume action runs, so a long policy on a big loop is not free.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume