Pipedream wait for webhook callback from a Sume video run

To make a Pipedream workflow wait for a webhook callback from Sume, call $.flow.suspend() in the code step that starts the run and pass the returned resume_url as communication.webhook_url. Pipedream pauses at the end of that step and resumes the execution when Sume POSTs the run's result, which it does once, when the run completes or fails.

Sume has no Pipedream app; this is a Node.js code step calling the API over HTTPS. Sume facts come from Create a run, Runs and results, and Run webhooks; Pipedream behavior comes from Pipedream's docs, read 2026-09-27. The webhook contract is covered in Sume Format run lifecycle.

How does $.flow.suspend fit a Sume run?

Each Pipedream rule below has a direct consequence for the run.

What does the step that starts the run look like?

Keep the API key in a Pipedream environment variable, which defaults to secret, and read it with process.env; Pipedream advises against putting keys in workflow code. Derive the Idempotency-Key from the event, and return the run id for later steps. In current code the webhook URL is part of the body the key is checked against, and resume_url belongs to one execution, so the same key sent from a new execution gets 409 idempotency_conflict and no second run starts.

import axios from "axios";

export default defineComponent({
  async run({ steps, $ }) {
    const order = steps.trigger.event;
    const { resume_url } = $.flow.suspend(2 * 60 * 60 * 1000); // 2 hours
    const { data } = await axios({
      method: "POST",
      url: "https://api.sume.com/v1/formats/sume/sume-product-commercial/runs",
      headers: {
        Authorization: `Bearer ${process.env.SUME_API_KEY}`,
        "Content-Type": "application/json",
        "Idempotency-Key": `order-${order.id}-v1`,
      },
      data: {
        instruction: "Make a vertical product commercial from the attached photo.",
        attachments: [{ type: "input_image", image_url: order.photo_url }],
        generation_spend_cap_usd: 20,
        communication: { webhook_url: resume_url },
      },
    });
    return { run_id: data.data.id };
  },
});

How long should the suspend timeout be?

Longer than the run can last. Sume force-finalizes a run as failed 90 minutes after created_at, and long-form host video typically finishes in 15 to 30 minutes, so the two hours above leave margin. The 24-hour default also works, but it holds the execution open for runs that will never call back: Sume sends nothing for a canceled or skipped run.

When the timeout passes, Pipedream cancels the workflow and the steps after the suspend never run, so keep the run id somewhere you can check it. Your timeout does not cancel the Sume run; it keeps running and billing.

What should the next step do with the callback?

Treat the callback as the signal to look, then read the run with your key, using the run id the first step returned: GET /v1/format-runs/{run_id} returns the same receipt Sume POSTed, in its data. That read is authenticated by your own key, so the workflow does not have to check Sume's signature on $resume_data.

• completed: publish primary_output_url, a durable media.sume.com URL.
• failed: read error, and artifacts[] for anything the run made.
• Requests to resume_url have the same limits as any HTTP request to Pipedream, which answers 413 over its body limit. Sume inlines receipts up to 1 MiB, so check that limit if your runs return large receipts.

When should I poll with $.flow.rerun instead?

When you would rather not depend on the callback. $.flow.rerun(delay, context, maxRetries) reruns the step after delay milliseconds, up to maxRetries times, which defaults to 10, and Pipedream shows it polling an external job until it completes. A 10-minute delay with 10 retries spans 100 minutes, past Sume's 90-minute bound; after the last retry the workflow moves to the next step, which should read the run once more. Pipedream does not charge for the time a workflow is suspended by rerun or suspend.