Make.com AI video scenario with Sume: HTTP and a webhook

A Make.com AI video scenario with Sume is two scenarios: the first sends POST /v1/formats/sume/{slug}/runs with the HTTP app's Make a request module and puts the second scenario's custom webhook URL in communication.webhook_url. The second starts when Sume POSTs the signed result, checks the signature with Make's sha256() function, and publishes the video.

Sume has no Make app; both scenarios make or take plain HTTPS calls. Sume facts come from Create a run and Run webhooks; Make behavior comes from Make's app docs and Help Center, read 2026-09-27. The signature scheme is explained in Signed webhooks for Sume video runs.

Why can't one scenario wait for the video?

Make a request waits at most 300 seconds: its timeout is a number of seconds from 1 to 300. A Format run answers its create call at once and then works for minutes; long-form host video typically finishes in 15 to 30 minutes. So scenario one only starts the run, and Sume calls scenario two once, when the run completes or fails.

How do I start the run with Make a request?

Configure the module as below, then send the run body. Catalog Formats take any key with formats:write.

{
  "instruction": "Make a vertical product commercial from the attached photo.",
  "attachments": [
    { "type": "input_image", "image_url": "https://example.com/product.jpg" }
  ],
  "generation_spend_cap_usd": 20,
  "communication": { "webhook_url": "<scenario two's webhook URL>" }
}

How do I set up the custom webhook?

Start scenario two with Webhooks > Custom webhook and copy its URL into the body above. Then:

• Turn on JSON pass-through, which passes the payload to later modules as a text string, and Get request headers, which makes the headers mappable. The signature check needs both.
• Leave the webhook's API key authentication off. It expects an x-make-apikey header, and Sume's webhook settings are only a URL and a mode.
• By default Make answers 200 Accepted and queues the request, inside Sume's 10-second attempt limit. A full queue answers 400 and more than 300 requests in 10 seconds get 429; Sume makes up to 10 attempts in all.
• Make's payload limit is 5 MB. Sume inlines receipts up to 1 MiB and sends payload: null with error.result_url beyond that.
• Make deactivates a webhook that is not connected to any scenario for more than 5 days and returns 410, so keep scenario two attached.

How do I check the signature with sha256()?

Make's sha256(text; [encoding]; [key]; [key encoding]) returns an HMAC when you pass a key, in hex by default. Make the text from the x-sume-webhook-timestamp header, a dot, and the pass-through body, and pass your Sume signing secret as the key. Then split() the x-sume-webhook-signature header on commas and use the array contains() to test for sume-v1= followed by your hash.

• For 24 hours after a secret rotation the header carries two entries, newest first, so never compare the whole header.
• Reject a timestamp outside a five-minute window.
• Read the secret on the Sume dashboard's Webhooks tab, or from GET /v1/webhooks/signing-secret with a key that has account:read.
• Make describes JSON pass-through as the way to access the original JSON. Prove the check before a paid run with Sume's Send test (/dashboard/webhooks, or POST /v1/webhooks/test-deliveries with account:write), which POSTs a signed webhook.test body to a URL you type.

What should scenario two do after verifying?

With JSON pass-through on, the body arrives as text, so send it through the JSON app's Parse JSON module to map its fields. Continue only when event is format.run.terminal; a Send test body carries webhook.test. The envelope rules in Sume Format run lifecycle then come down to three checks:

• Dedupe on request_id. It equals the run id and repeats on every retry.
• status is OK when the run completed and ERROR when it failed. On OK, publish payload.primary_output_url, a durable media.sume.com URL.
• Canceled and skipped runs never deliver a webhook. When nothing arrives, or payload is null because the receipt was over 1 MiB, read GET /v1/format-runs/{run_id} with your key; its data is the same receipt.