Add video processing to Activepieces

Flow builders are good at moving small pieces of JSON between APIs. They are bad at waiting. The same problem shows up in n8n, and it has the same answer there. A transcode that takes four minutes does not fit the shape of a step expected to answer immediately, and the usual workaround is a loop that asks whether the job is done yet until it is.

Short version#

Rendobar has an Activepieces piece. It is on npm as @rendobar/piece-rendobar, and Activepieces installs it by package name from Settings, Pieces, Install Piece. It adds nine actions and two triggers.

The part that matters is what happens while a job runs. Run a Media Job creates a waitpoint, hands Rendobar the resume URL as the job’s callback, and parks the flow. Nothing executes in between. In a verified run against production the flow paused 12 seconds in and finished at 20 seconds, and the step itself accounted for 546 ms.

Waiting without burning a worker#

A polling step is not free. It occupies an execution for the entire job, and on a hosted plan that is the resource you are actually paying for. The longer the job, the worse the trade.

A waitpoint inverts it. The flow submits once, stops, and resumes only when something external says it is time.

There is a failure mode worth naming. A waitpoint is useless if the callback cannot reach it, which is the normal case on a laptop or behind a firewall. The action checks whether the resume URL it was given is publicly reachable, and if it is not, it polls instead. That fallback needs no configuration, and it is why the Maximum Wait field exists.

The form is built from the API, not from a list#

Most integrations hardcode their fields. Every new capability upstream means a new release downstream, and an integration that is a month behind is one that cannot reach half the product.

This piece reads GET /jobs/types/{type}/schema and builds the form from the response. Choosing a job type replaces the fields underneath it with that job type’s real parameters, descriptions included.

All nine live job types appear in that dropdown, and a job type that ships next month appears without a piece release. The same schema drives the Variant dropdown, which is why it reads “Not used by this job type” rather than sitting there empty and ambiguous.

What else is in it#

Eight more actions round out the surface: read a job, list recent jobs, read a job’s logs, upload a file, share an output as a public URL, cancel a running job, check the account balance, and call any endpoint the piece does not wrap. Two triggers fire when a job finishes, one on a webhook and one by polling for instances that cannot receive one.

Upload is worth a note. It streams rather than buffering, so putting a large file through a flow does not require holding it in memory first.

Installing it#

The package is MIT licensed and publishes from CI with npm provenance, so the tarball on the registry is attested to have been built from the public repository. It has zero runtime dependencies, because the framework is inlined at build time the way every piece in the Activepieces catalog does it, and that makes the artifact 139 KB from 936 KB of raw input.

Where this stops#

Two limits, both real.

Activepieces Cloud gates custom pieces behind the Ultimate plan. Installing a piece that is not in the Activepieces catalog is an Enterprise feature on their pricing page. Self-hosted instances have no restriction. So this reaches self-hosted users and Ultimate customers, and not the Free, Plus or Team tiers.

The timings above are one run. Twelve seconds to pause and twenty to finish describes one ffmpeg job on one file, and the pause point depends on how quickly Rendobar picks the job up. What does not vary with load is the shape: the flow holds no execution while it waits. That is a property of the waitpoint, not a measurement.

If you want the same behaviour from code rather than a flow, the job type schema endpoint is the same one the piece reads, and per-job callbacks are the mechanism underneath the waitpoint.