Azure Logic Apps HTTP action times out at 120 s: long Sume runs

A Logic Apps HTTP action cannot wait for a Sume video run, but it does not need to. POST /v1/formats/{handle}/{slug}/runs answers with a 202 receipt right away, so the action finishes in well under the 120-second outbound limit, and the finished result arrives later through a signed webhook or a status poll.

The risk is not the timeout. It is the retry policy. Logic Apps retries failed HTTP calls on its own, and a retried create without an idempotency key is a second paid run. This post lists the Logic Apps limits that matter and the Sume fields that make the pattern safe.

The Logic Apps limits that matter here

Microsoft's limits and configuration reference says an outbound request, such as a call made by the HTTP action, times out after 120 seconds in multitenant Azure Logic Apps and 225 seconds by default in single-tenant (read 2026-10-10). Its tip for longer operations is to use an asynchronous polling pattern or an Until loop.

Two other rows decide the design. The default retry policy allows 4 attempts, and an Until loop has a default timeout of one hour. Sume's side is documented in Runs and results: a non-terminal run carries expires_at, the deadline after which Sume force-finalizes it as failed, set 90 minutes from created_at (or earlier when the run goes silent).

Pattern A: HTTP action plus a webhook trigger

Create the run with an HTTP action and send communication.webhook_url pointing at a second workflow that uses a Request trigger, or at a small function in front of it. Sume posts one format.run.terminal event when the run completes or fails, expects a 2xx within 10 seconds, and does not follow redirects. Verify x-sume-webhook-signature against the raw body where you control the bytes, then hand the event to the workflow.

Before a real run, call POST /v1/webhooks/test-deliveries to confirm that your trigger answers inside the 10-second budget. Dedupe on request_id, which equals the run id and is stable across Sume's up to 10 attempts.

Pattern B: poll with an Until loop

If you cannot expose an endpoint, put the run id from the 202 into an Until loop that reads GET /v1/format-runs/{run_id}/status and exits when status is completed, failed, canceled or skipped. Back off between reads, because video work takes 15 to 30 minutes and a read each second only spends rate limit.

Raise the loop timeout deliberately. The default one-hour Until timeout is shorter than Sume's 90-minute expires_at ceiling, so a slow run can outlive your loop. A loop timeout does not cancel the run: it keeps executing and spending, so store the run id and read it again later, or call POST /v1/format-runs/{run_id}/cancel.

Make the create call safe to retry

Set the Idempotency-Key header from the record that triggers the flow, for example a row id plus a version you bump only when you want a re-run. Do not use a new GUID per request, because then the header has no effect and each Logic Apps retry creates a new run. Add generation_spend_cap_usd so one bad input cannot spend more than you intended; the platform maximum is $500 and a Format without its own cap defaults to $400.

The same key with a different body returns 409 idempotency_conflict, and a concurrent duplicate returns the retryable 409 idempotency_key_in_use. Treat 200 and 202 as success, 429 and 503 as retry-with-the-same-key, and 402 insufficient_credits as a stop.