Zyllio

Zyllio's SaaS API runs a software business on the no-code platform. Workflows clone an application per customer, configure and rename it, keep it in step with the template, and publish it.

Verified 5 actions API key available

Zyllio website Platform Documentation Capability data verified 2026-08-25

A new release of the product template is finished in the Zyllio studio

List Applications returns every customer clone with its owner, its counts, and its live URL

The agent compares each clone's screen and table counts against the template's to find customization

The agent confirms the sync direction, because the target is overwritten and the source is not

The clones that would lose per-customer work are listed with the owners who would notice

The operator approves the sync list and the screen and theme flags before anything is overwritten

What This Integration Enables

This connector has five actions, and that is the product rather than a gap in the coverage. Zyllio's SaaS API is not for reading an application's data. It is the API for running a software business on Zyllio: you keep one application as the product, you clone it per customer, you keep the clones in step with it, and you publish. Every operation here serves one of those four verbs, and there is nothing else because there is nothing else that job requires.

That makes it an unusually clean fit for a flow. The clone-configure-publish sequence is exactly the kind of provisioning that should be attached to a payment event rather than to a person's calendar, and the release pass across a customer list is exactly the kind of repetitive fan-out a flow does better than a human with a spreadsheet. What the flow has to respect is the boundary Zyllio draws for itself: create, update, and sync all change a draft, and the customer keeps seeing the previously published version until Publish Application runs. That built-in pause is genuinely useful, and it is also why the human-in-the-loop step on this page sits earlier than you would expect, at the operation that destroys work before anybody has a chance to see it.

Without FlowRunner

Onboarding is a manual clone Every new customer means opening the studio, duplicating the app, renaming it, and remembering to publish

Updates land unevenly A template improvement reaches whichever customers somebody had time to get to that week

The fleet lives in somebody's head Who is on which version, and which application belongs to which account, is not written down anywhere reliable

With FlowRunner

Signup provisions the product The clone, the naming, and the publish are steps in the same flow that handled the payment

One release, one controlled pass A template change reaches the whole customer list in a single run with a named exception list

The fleet is a queryable list Owner, contact address, screen and table counts, and live URL come back on every listing

Use Case Scenarios

A subscription starts and the customer's application is already waiting

A subscription is created in Stripe. The agent calls Create Application to clone the product template, then Update Application to name it after the customer and set its description and icon. The new application's id is written back to the account record in HubSpot so support can find it later without asking anybody. The draft is configured and the account manager is shown what it will look like. Once it is confirmed, Publish Application makes the live URL serve it, and the welcome message goes out with a link that already works. Nothing about that sequence requires the studio to be opened.
A release reaches every customer, on purpose

The template gains a new screen. The agent lists the fleet, groups the clones by whether they carry any per-customer screens of their own, and proposes a sync plan: the standard clones get screens and theme, the customized ones get theme only, and two accounts on a paused contract get nothing. After that plan is approved, the agent runs Sync Application per customer with the flags the plan set, then Publish Application for each one, and posts a completion summary to Slack naming any application that did not publish. A release that would otherwise have been a long afternoon becomes a reviewed list and a run.
The fleet as an operating report

On a schedule the agent calls List Applications and appends the result to Google Sheets. The listing carries the owner's name and email alongside screen, table, and plugin counts and the live URL. That one call answers questions that usually require a database: which customers actually use the tables the product ships with, which applications have drifted furthest from the template, and which live URLs belong to accounts that churned last quarter. The same data drives a follow-up flow that flags accounts whose application has not been published since a release went out.

Human-in-Loop Highlight

Sync Application copies screens and theme from the template into a customer's application, and it overwrites rather than merges. Any screen a customer asked for, any layout somebody adjusted for them, is gone the moment the call returns. This connector has five operations and none of them is an undo: there is no version history, no diff, and no restore. The only way back is somebody rebuilding the screens in the studio from memory. Getting the direction wrong is worse still, because the application named as the target is the one that gets overwritten, and reversing the two arguments pushes one customer's application over the template every future clone is made from. Notice that Zyllio's own draft-until-published boundary offers no protection here, because sync destroys the draft whether or not anyone ever publishes it. So the agent builds the plan and stops. It posts: "Template release is ready. 34 customer applications are in scope. 6 of them carry more screens than the template, which means per-customer work that a screens sync would erase. Sync all 34 with screens and theme, sync those 6 with theme only, or exclude them?" The operator answers, and then the agent runs 34 syncs and 34 publishes without further help. Doing the fan-out is the machine's job. Deciding whose work gets overwritten is not.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

5 actions

The Fleet

List Applications Returns the applications linked to the API key. It is the connection test and the fleet inventory in one: each row carries the owner's name and email, the screen, table, and plugin counts, and the live URL, which is what a Zyllio operator needs to see who has what. The template appears here alongside the clones, because Zyllio has no separate template object.

Provisioning and Release

Create Application Clones one of your applications into a new one. This is the operation the whole API exists for: the product is one application, and every customer gets a copy of it. The response carries the new application's id, which is what the rest of the flow works with.
Update Application Changes an application's name, description, or icon. Those three fields are the whole surface here, because screens, data, and theme are changed in the studio or brought over from the template with a sync.
Sync Application Copies screens and theme from a source application into an existing one, which is how a Zyllio product ships an update to its customers. It overwrites rather than merges, the screen and theme flags exist so one can be excluded, and the application named as the target is the one that is changed. The operation this page's human gate exists for.
Publish Application Publishes an application so its live URL serves the current version. Nothing reaches a customer until this runs, because create, update, and sync all change the draft. It is the step a clone-and-configure flow most often forgets, and the reason a newly provisioned customer sometimes sees the wrong thing.

Frequently Asked Questions

What can FlowRunner do with Zyllio?

FlowRunner agents can run List Applications, Create Application, and Update Application in Zyllio, plus 2 more actions.

Does connecting Zyllio to FlowRunner require OAuth?

No. Zyllio connects to FlowRunner with an API key, no OAuth flow required.

Can Zyllio trigger a FlowRunner workflow automatically?

Zyllio doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Zyllio

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us