Pipedream 750-second timeout: poll loop or Sume webhook?

Use a second workflow triggered by the Sume webhook, not a poll loop inside one Pipedream step. A 750-second run cannot be relied on to outlast a render, while a webhook-mode submit returns a 202 with the job id immediately and Sume calls you back when the job is terminal.

What are Pipedream's timeouts?

Pipedream's limits page, read 2026-10-01, gives these numbers.

What does a poll loop cost you?

With async mode you poll status_url until terminal is true, then GET result_url once result_ready is true. That works while the loop stays inside the step's timeout, but you spend run time waiting and the step dies if the job is slower. If it times out, keep the job id and read the job again; do not resubmit, because the first submit already started paid work. See Jobs and results.

How does the webhook version work?

Step one sends mode: "webhook" with webhook_url, pointing at a second workflow's HTTP trigger, and ends. Sume sends terminal job events only (job.completed, job.failed, job.canceled). Each attempt has a 10s timeout and there are up to 10 attempts, so acknowledge fast and do heavy work after storing the event. Verify the signature, and dedupe on job_id. The pattern with suspend and resume is in Pipedream AI video workflow.

Do I still need polling?

Keep it as a backup. Ten refused attempts leave a failed delivery and a job that still reached its real terminal state, so a scheduled workflow that reads status_url for jobs with no event covers the gap.