Publora is in the Zapier app directory now. I didn't do it to tick a box on some distribution list. My job is making our product easy to live with, and if a user has an agent that can wire us in deeper so they don't have to build the plumbing themselves, I'll go make that happen. Zapier is exactly that case: it connects Publora to thousands of other apps, so nobody has to hand-roll the integration.
Worth it. I'd just add that "a no-code platform" and "publishing your own app on a no-code platform" turn out to be two very different Zapiers.
Prove it works for users who don't exist yet
Here's the requirement I reread three times, sure I'd misunderstood.
To submit an app for review, every trigger, every action, and every search has to be tested inside a live Zap, turned on, with at least one successful run in the history. You can't delete those Zaps; the reviewer can ask to see them.
So the logic goes like this. You want to publish an app so people can start using it. But to publish it, you first have to prove it's already being used. Run every component for real, as if you had the users you're publishing it to attract. The app isn't in the directory yet, and a history of real use already has to exist.
You end up standing in for your own users who aren't there yet. You build the Zaps, run each one, make sure every one has a green run, and don't touch them afterward.
A routine task you run like a rocket launch
The second surprise. My tasks here are the plain ones: schedule a post, publish a post, delete a post. This isn't a satellite launch. It's what our API does a thousand times a day over one line of code.
As a Zapier app, each of those ordinary tasks has to be wrapped, configured, and run live on its own. Create Post, Update Post, Delete Post, two triggers, two searches, each with its own test run under the validator's eye. Scheduling a post is something I can describe in one sentence. Here it became a component with a run history.
Then the small surprises a "no-code" promise doesn't quite imply. The connection label, the line that tells the user which account they connected, couldn't just read a field. {{connections.0.username}} doesn't work, because Zapier won't follow a path into an array. So the label needs actual JavaScript:
const connections = bundle.inputData.connections || [];
const first = connections[0] || {};
return { label: first.username || 'Publora' };
That's in a box labeled "label." On a no-code platform.
The triggers are the other place the word stretches. These aren't polling. They're REST Hooks on our own webhooks, which means subscribing and unsubscribing are API calls you define by hand:
// subscribe
const options = {
url: 'https://api.publora.com/api/v1/webhooks',
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Accept': 'application/json',
'x-publora-key': bundle.authData.api_key,
},
body: {
name: 'Zapier - Post Published',
url: bundle.targetUrl,
events: ['post.published'],
},
};
return z.request(options).then((response) => {
response.throwForStatus();
return response.json.webhook;
});
What subscribe returns is not incidental. Zapier hands it back to you as bundle.subscribeData, and unsubscribe reads the webhook id out of it to call DELETE /webhooks/{id}. Return the wrong shape and the Zap turns on cleanly, then never cleans up after itself.
A few more edges, for anyone about to do this. A field's type and key are locked after you create it, and if you get the shape of a step wrong and you don't fix it, you recreate it from scratch. The first published version gets locked for editing once real people are on it, so you clone it into a new one and make changes there. And the editor session expires with a cheerful failed csrf; you reload, and the code you just wrote is gone.
None of it is fatal. I just walked in with a one-line task and walked out with versioning, user migrations, and a chunk of JavaScript in a field called "label."
Where it landed
The app passed review after eight rounds of reviewer notes, then out into the directory with a Beta tag. Zapier's beta runs ninety days, and you leave it one of two ways: pull in enough active users, or embed their widget inside your own product. Familiar shape. The platform holds you at "not quite yet," and the key out is either bring it an audience or let it inside your product.
I don't regret the trip. The directory listing genuinely lowers the effort for anyone who wants to post from whatever workflow they already live in, and I wrote them a separate tutorial for that. But the "no-code" part I left somewhere around the halfway mark. For the user assembling a Zap out of ready-made blocks, sure, no code. For the person making those blocks, no-code ends exactly where anything past a single step begins.
For the record, I'm not an engineer. My job is getting people to use our product, and I built this with Claude: it wrote the code, I led, tested, and sent it back to redo. Which is maybe the honest shape of "no-code" in 2026 anyway. The code didn't disappear. It just moved to someone else, or something else.
Did your no-code platforms keep the promise when you went past a single step? Or did you end up opening the code editor too?
