Power Automate HTTP Webhook action: wait for a callback

The Power Automate HTTP Webhook action makes a subscribe request to an API, passing the flow's own callback URL from listCallbackUrl(), and then pauses the flow until that API sends an HTTP POST to the callback URL. The POST's headers and body become the action's outputs. Use it when an API starts slow work and can call a URL when the work ends, so the flow waits without a polling loop.

Microsoft documents the action on its Azure Logic Apps pages: HTTP Webhook trigger and action, the triggers and actions reference and the expression functions reference. Power Automate's FAQ says Logic Apps provides the same features as Power Automate plus more, and its limits page sets the flow run ceiling. Sume facts come from Create a run and Runs and results. All were read on 2026-09-29. Sume has no Power Automate connector; this is a plain HTTPS call.

How does the HTTP Webhook action work?

When the action runs, it calls the subscribe endpoint with your method, URI, headers and body. Put @{listCallbackUrl()} in the body where the API expects its callback address. The flow then pauses. When a POST reaches the callback URL, the action passes that request's data on, unsubscribes, and the flow continues.

• Subscribe Method and Subscribe URI are required; the subscribe body is optional.
• The subscribe request can carry a retry policy for 408, 429, 5XX responses and connectivity errors.
• Unsubscribe is optional; Microsoft's own timeout example leaves it as {}.
• The callback URL's SAS token has no time-based expiry by default and stays valid for the run. Canceling, disabling or timing out the workflow, or rotating its access keys, invalidates it.

How do I point a slow API's webhook at the flow?

Make the API's create call the subscribe request, and put the callback URL in the field the API uses for its webhook. For a Sume Format run, that is communication.webhook_url on POST /v1/formats/{handle}/{slug}/runs. Sume answers 202 Accepted with a run receipt and POSTs the terminal receipt to the URL when the run completes or fails. The action's inputs, as they appear in the workflow definition:

{
  "type": "HttpWebhook",
  "inputs": {
    "subscribe": {
      "method": "POST",
      "uri": "https://api.sume.com/v1/formats/acme/product-promo/runs",
      "headers": {
        "Authorization": "Bearer @{body('GetSecret')?['EnvironmentVariableSecretValue']}",
        "Content-Type": "application/json",
        "Idempotency-Key": "item-@{triggerBody()?['ID']}-promo-v1"
      },
      "body": {
        "instruction": "15-second vertical promo for this product.",
        "input": { "product_url": "@{triggerBody()?['ProductUrl']}" },
        "generation_spend_cap_usd": 20,
        "communication": { "webhook_url": "@{listCallbackUrl()}" }
      }
    },
    "unsubscribe": {}
  },
  "limit": { "timeout": "PT2H" }
}

Will Sume accept the flow's callback URL?

It should. Sume requires a public HTTPS webhook URL and refuses localhost, private ranges, credentials in the URL and plain HTTP with 400 invalid_request. Microsoft's sample callback URL is https on a public host with :443, the default HTTPS port; current Sume code checks the parsed URL's port, which is empty for :443 on https, so only a non-default port is refused.

The key for the Authorization header should come from a secret, not the flow itself; Power Automate HTTP request API shows the Key Vault step named GetSecret used above.

How long will the flow wait?

Until the callback arrives or the action times out. A timed-out action is marked Cancelled with the ActionTimedOut code. Set limit.timeout (ISO 8601) to a bit more than the longest time your job can take: a Sume run still going 90 minutes after created_at is force-finalized as failed, which still sends the webhook.

What can go wrong?

• A canceled or skipped Sume run never sends a webhook, so the flow waits until limit.timeout. Keep the timeout finite.
• Nothing in Microsoft's description of the action checks Sume's HMAC signature. Treat the callback body as a notice: read run_id, then fetch GET /v1/format-runs/{run_id} with your key and branch on data.status. The same fetch covers a delivery whose payload is null because the receipt was over 1 MiB.
• Build Idempotency-Key from the item, not the moment. If a later flow run sends the same key with a different callback URL, the body differs, so Sume answers 409 idempotency_conflict and nothing runs.
• The status field is OK when the run completed and ERROR when it failed. Signed webhooks for Sume video runs covers verification for receivers that can run code.