Pipedream Workflows shuts down March 31, 2027: move Sume calls

Pipedream's docs say Workflows and String shut down on March 31, 2027, and existing workflows keep running normally until then. A Sume workflow built there is easy to move, because Sume only needs three things from the tool: an HTTPS call that submits a job, a status poll, and a public HTTPS endpoint that receives a signed webhook. Rebuild those in n8n, Make, Activepieces, Apps Script or your own server, send new jobs a new webhook_url, and poll any job still in flight.

This post uses the announcement on Pipedream's Workflows docs (read 2026-10-02) and Sume's Jobs and results and Webhooks pages.

What did Pipedream announce?

The page describes a maintenance mode: no new signups or subscriptions, no new Workflows features, and a full six months to migrate. It also says Pipedream Connect (the Connect API, MCP servers and the API proxy) is not affected.

Which parts of a Sume workflow depend on Pipedream?

Usually three. The HTTP step that calls the Sume submit endpoint, the trigger URL you passed to Sume as webhook_url, and any state kept in Pipedream, such as a data store of job ids. The first and third are plain logic you can recreate anywhere. The second needs care.

Sume's webhook page is explicit that Redeliver does not change the destination URL, and that a new URL is a new job. So a job created with a Pipedream trigger URL keeps pointing there. Once that workflow is gone, its delivery fails and the job still reaches its real terminal state. Sume's docs say delivery is an optimization, never the only recovery path, so poll status_url for those jobs.

If you stored a Sume API key as a Pipedream environment variable or connected account, Pipedream says that data is deleted by April 30, 2027. Create a key for the replacement system in the API Keys dashboard and revoke the old one when the cutover is done.

How do I list the jobs that still point at Pipedream?

GET /v1/jobs returns jobs newest first, up to 100 per page, filterable by status, and each job carries its communication_mode. Run this once before cutover to see which queued or processing jobs were created in webhook mode. It prints each job id with the idempotency_key it was created with, so you can match it back to your own rows.

import json, os, urllib.request

def get(path):
    req = urllib.request.Request(
        "https://api.sume.com" + path,
        headers={"Authorization": "Bearer " + os.environ["SUME_API_KEY"]},
    )
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

def main():
    for status in ("queued", "processing"):
        cursor = None
        while True:
            q = f"/v1/jobs?limit=100&status={status}"
            if cursor:
                q += "&starting_after=" + cursor
            data = get(q)["data"]
            for job in data["jobs"]:
                if job["communication_mode"] == "webhook":
                    print(job["id"], status, job.get("idempotency_key"))
            cursor = data.get("next_cursor")
            if not cursor:
                break

main()

What do I rebuild, and in what order?

First, make the receiver in the new tool and verify the signature on the raw body with your workspace signing secret, as the Webhooks page describes; return any 2xx only after you have stored the event, and treat job_id as your idempotency key. Second, move the submit step and keep sending an Idempotency-Key on every paid submit. Third, switch new jobs to the new webhook_url and keep a status poll as the backup. Last, let the old jobs finish, read their results by polling, and turn the Pipedream workflow off.

Pipedream's own timeout and body-size limits stop mattering after the move; the new tool brings its own, and Sume's answer to them is the same: submit in async or webhook mode and never hold a request open for a render.