Hosted visual flow or hand-written webhook handler?

Two shapes, one event

Something has to happen when an asset lands: a moderation check, an alt-text pass, a row written back to a catalogue. There are two honest ways to build it.

The first is a handler you write. Cloudinary posts a signed notification to an HTTPS endpoint you own, and your code takes it from there — the notifications reference covers which events fire and how the signature is verified. The logic lives in a repository, in a language your team already uses.

The second is a hosted visual automation: a canvas of blocks with a trigger at the top, running on someone else’s infrastructure. Cloudinary’s is MediaFlows, which ships media-aware blocks, a chat-driven Workflow Agent and prebuilt flows; general-purpose hosted automation platforms fill the same slot, and everything below applies to them too, because the argument is about shape rather than vendor. The trigger side is broadly comparable either way — see the trigger types available to a hosted media automation.

What it costs to process the first event

A hand-written handler needs a deployment target, a secret store, retry logic and an on-call owner before it processes a single event. Concretely: somewhere to run (a Worker, a Lambda, a container), somewhere to keep the API secret that is not the repository, a retry path for when the downstream call returns a 500 — a webhook delivery you drop is simply gone — and a name on the rota. None of that is the automation. All of it is prerequisite, and all of it is real work.

A hosted flow needs none of them. Trigger, blocks, save. PowerFlows go one step further with prebuilt flows for moderation, UGC deletion, multilingual alt text and CSV upload, so for those four jobs the build step is configuration rather than code — the shape of the work in automating moderation of user-generated media.

The honest caveat: this asymmetry is largest for your first handler and shrinks for your twentieth. If the service, the secret store, the retry queue and the rota already exist, adding one more endpoint is often an afternoon.

What it costs to keep running

This is the criterion people underprice. With a hosted flow, the platform owns backend maintenance, scaling and library upgrades — and that recurring cost is what makes small internal services expensive long after they were cheap to write. The runtime goes end-of-life. The HTTP client picks up a CVE. Traffic triples on a campaign day. Somebody has to be awake for it. Nobody budgets for any of that, because the original build took two days.

Moving it to the vendor means inheriting their limits, their outages and their release schedule instead. Your own quota still applies to both options equally: on the Free plan the Admin API is capped at 500 requests per hour, per Cloudinary’s pricing page (checked 2026-08-18), and a chatty flow hits that ceiling exactly as fast as a chatty handler.

Who is allowed to change it

Visual flows are legible to people who cannot read the source. A producer, a moderation lead or a marketing ops person can open the canvas and see what fires, in what order, under what condition. That changes who is permitted to modify the workflow, and it is usually the actual reason the automation was asked for in the first place. When someone asks whether campaign uploads can be auto-tagged, they generally mean: can my team change what auto-tagging does without filing a ticket.

A handler in a repository answers no to that. Every change is an engineer’s change, scheduled against an engineer’s other work. That is a feature when the logic is subtle enough that a wrong edit is expensive, and a bottleneck when it is not.

How far the legibility goes depends on which canvas style you use — the trade is laid out in PowerFlows against EasyFlows. Legibility is not only a human benefit either: MediaFlows is drivable from its own MCP server, so an agent can build and edit the same flow, and the pricing page above lists MCP server access on every plan including Free. Setup is covered in configuring the MediaFlows MCP server.

Version control is the honest trade

Here the hosted option loses cleanly, and no amount of canvas polish fixes it. A canvas has no diff, no branch and no pull request. Reviewing a change is a conversation rather than an artifact. You cannot ask for approval before an edit takes effect, cannot revert to a known-good commit, cannot bisect to find the change that broke Tuesday, and cannot answer who changed this, and when six weeks later beyond whatever audit trail the platform happens to keep.

A handler in git gives you all of that as a side effect of being code: blame, revert, review, staged rollout, tests in CI.

Weigh it by blast radius rather than by principle. A flow that adds alt text degrades into missing alt text. A flow that deletes user-generated media after a retention window can destroy customer assets on one mistyped condition. The second wants a reviewable artifact even if the first genuinely does not.

Side by side

Criterion	Hand-written handler	Hosted visual flow
Before the first event	deployment target, secret store, retry logic, on-call owner	none
Ongoing maintenance	yours: runtime, scaling, library upgrades	the platform’s
Who can edit	engineers only	anyone who can read the canvas
Reviewing a change	diff, branch, pull request	a conversation

Which to pick when

The threshold is roughly whether more than one role will edit the logic. Single-owner logic belongs in a repository; cross-role logic belongs where the other roles can see it.

• Pick the hosted flow if a non-engineer will change the rules — thresholds, tags, which folder, which locale. That is the case the canvas exists for, and routing those edits through an engineer converts a five-minute change into a sprint item.
• Pick the hosted flow if the job is one of the prebuilt ones — moderation, UGC deletion, multilingual alt text, CSV ingestion — even when engineering owns it, at least until the blocks stop covering what you need.
• Pick the hand-written handler if engineering is the only role that will ever touch the logic. You give up nothing you wanted and you keep the diff.
• Pick the hand-written handler if a change must leave a reviewable artifact: destructive operations, retention rules, anything you will have to reconstruct for an auditor or an incident review.
• Pick the hand-written handler if the four prerequisites already exist and are staffed. The setup argument is what makes hosted attractive, and it evaporates once the platform is already yours.

If your hosted platform can call an HTTP endpoint, the split is available too: keep the trigger and the parts other roles edit on the canvas, and put the one step that needs tests and review behind your own handler.