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.

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.
| Setting | Documented value |
|---|---|
| Default retry, Low profile | Up to 2 retries at exponentially increasing intervals, last one about 10 minutes out |
| Default retry, Medium and High profiles | Up to 12 retries at exponentially increasing intervals, last one about 1 hour out |
| Retry attempts (custom policy) | 90 maximum |
| Retry minimum delay | 5 seconds |
| Retry maximum delay | 1 day |
| Action counting | Successful 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
- Power Automate as a Sume webhook receiver: respond within 10 seconds
Power Automate allows 120 seconds for an inbound HTTP request, but Sume gives each webhook attempt 10 seconds. Put the Response action first.
- Render deploy hook returns 202: start a Sume run after a deploy
Render deploy hooks return 200 when a deploy starts and 202 when queued. Call one, then start a Sume Format run for the release only once it ships.
- Roo Code .roo/mcp.json overrides the global Sume MCP entry
In Roo Code a project .roo/mcp.json wins over global mcp_settings.json when both name the same server. Use one name for Sume and keep the key in one file.
- SendGrid ECDSA event webhook vs a Sume HMAC verifier: two checks
SendGrid signs event webhooks with ECDSA, while Sume uses HMAC SHA256. Here is why one verifier will not cover both and how to start a Sume run from an event.
Written by Sume