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.

If you receive Sume job webhooks in a Power Automate flow that starts with the HTTP Request trigger, add the Response action first. Power Automate lets an inbound request run for 120 seconds, but Sume waits only 10 seconds per delivery attempt, so the shorter number is the one that binds.
A flow that does real work before it answers can look fine in Power Automate and still fail every delivery from Sume's side.
The two clocks
The Power Automate figures are from Microsoft's limits page. The Sume figures are from the webhooks page.
| Side | Value | What it means |
|---|---|---|
| Power Automate inbound request | 120 seconds | Documented limit for requests that trigger instant flows, including the HTTP Request trigger |
| Power Automate Response action | Always responds within that limit | Actions after the response action continue running beyond it |
| Sume delivery timeout | 10 seconds per attempt | A slow endpoint uses the budget and Sume retries it |
| Sume delivery attempts | Up to 10, 30 seconds apart by default | After that the delivery is marked failed; the job itself is still complete |
Flow layout
Start with the HTTP Request trigger. Add a Response action that returns status 200 as the very next step. Everything else (fetching the result, writing a row, posting to Teams) goes after it. Microsoft's page notes that actions after the response action keep running, so the flow can finish slowly without holding Sume's attempt open.
Sume's rule is to store the event durably and return any 2xx. In a Power Automate flow, the practical way to store it before answering is a single quick action, such as adding a row, ahead of the Response; if even that is slow, answer first and accept that a failed later step is recovered by polling.
Dedupe on job_id
Delivery can repeat. Sume says to treat job_id as the idempotency key on your side. Check whether the job id already exists in your list or table before triggering any paid follow-up. The payload carries event, job_id, status and artifact URLs, so you can fetch the file later rather than moving bytes through the flow.
- Response action 200 first, work after.
- Dedupe on job_id before any paid follow-up.
- Keep a poll of the job status URL as a backup for deliveries that never arrive.
- Verify the sume-v1 signature if you can read the raw body and headers in your flow design; Sume signs the raw body over timestamp.body.
What this does not cover
This post only concerns a flow that receives the callback. To make the flow wait for a callback after it submits, see the HTTP Webhook action post. Sume is not a Power Automate connector; everything here uses the generic HTTP triggers and actions.
Sources
Related posts
More in Integrations
- 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.
- Shopify X-Shopify-Webhook-Id as the Sume Idempotency-Key
Shopify retries a failed webhook 8 times over 4 hours. Derive the Sume Idempotency-Key from the webhook id so each delivery makes one run, never two.
Written by Sume