Automation stopped being an optional extra for small software companies a while ago. Almost 60% of businesses have already put automation solutions in place, and 73% of employers intend to accelerate the automation of processes and tasks by 2030. If your customers already run their week through connected apps, the app directory they search when they want two tools to talk to each other is a place you probably want to be.
We build FormaPortal, a client portal product, and in September 2026 we took it through Zapier’s publishing process. This is a write-up of what that actually involved, in the hope it saves someone else a few evenings of guessing.
One disclaimer before anything else. Everything below is our experience in September 2026. Zapier is a moving platform: features get added, screens get rearranged, requirements get tightened. Your run through it may differ in the details. What this should give you is a sense of how hard or easy the whole thing is, which is the question we wanted answered before we started and could not find a straight answer to.
Platform UI or Platform CLI
Zapier gives integration developers two ways in. The Platform UI is a web interface where you fill in everything about your integration in a browser: authentication, triggers, actions, fields, copy. The Platform CLI is the other route, where you write the integration as code and push it.
Not every option is exactly the same across the two, but they are similar enough. Unless you are doing something quite specific, the gap will not stop you. From what we can tell, the Platform UI is the more common choice, and the CLI is the better fit if you expect to update the integration regularly and want version control and code review around every change.
We went with the Platform UI. Our integration does not change often, and we were not experienced enough with the platform to do everything from the command line on the first attempt. Seeing the whole shape of the integration on one screen was worth more to us than being able to diff it. If you are undecided, that is a reasonable way to pick: choose the CLI when the integration is going to be a living part of your codebase, and the UI when it is a stable surface you set up once and revisit occasionally.
You probably do not need a Zapier-specific API
This was the part we had most wrong going in. You can integrate more or less any REST API, and if you already have OAuth v2 that was built for general use rather than for Zapier, it can be used as it is. There is no requirement to build a separate API just for Zapier, which removes the biggest imagined cost of the project.
Whichever API you connect, Zapier still has rules about how it is exposed. Every endpoint the integration touches has to be served over HTTPS, including the authentication and login pages. Client IDs and client secrets belong in the platform’s credentials section or in environment variables, never hard coded into the integration. Tokens issued per user do not get stored there at all.
Triggers and actions
In the early days of Zapier the only product was the Zap. There are several other tools in the ecosystem now, but the Zap is still where an integration lives, and for Zaps there are two primary types of integration to build.
A trigger is your application sending a signal into a Zap. Something happens in your product, Zapier picks it up, and the user decides what should happen next in whichever apps they use. An action works the other way: another application calls your application through Zapier’s infrastructure to make something happen.
Triggers themselves come in two shapes, polling and REST Hook. A polling trigger has Zapier check one of your endpoints on a schedule, somewhere between every 1 and 15 minutes depending on the user’s plan, with your endpoint returning items newest first. A REST Hook trigger has your application push to a webhook URL that Zapier generates for each Zap, which runs closer to real time and spares your API a stream of polling requests it mostly answers with nothing.
The advice in Zapier’s own documentation is worth repeating: design triggers around how people use your product, not around which endpoints you happen to have lying around.
Defining your events so users can map them
Every application and every business is different, and terminology rarely lines up between two products. Because of that, you have to define your triggers and actions carefully enough that an end user can work out which piece of data goes where when they are wiring up a Zap.
Zapier asks you to give each field a type and a user-friendly name. We have a field called formVersion with a type of Integer, and its user-friendly name is “Form Version”. That is a small piece of work repeated across every field you expose, and it is the difference between a Zap someone can configure in two minutes and one they abandon halfway through. Field naming also comes up in review, so it is cheaper to do it properly the first time than to rename things later.
Accounts and the portal-picking problem
When somebody uses your integration, the first thing they do is connect to your application if they have not already, so that Zapier can show their account information in its own interface.
In our case that is more than a single account. Customers can add all the portals they run, and when they build a Zap they need to choose which portal it should apply to. We solved that with a hidden trigger that lists a customer’s portals, which Zapier then renders as a dropdown at the point of configuration. If your product has a similar layer of workspaces, sites, teams or tenants above the account, expect to build something like it. The same pattern applies to anything a customer might want to automate around, because each one needs the same question answered first: which portal are we talking about?
The validation panel is the best resource you get
On the Zapier developer screens there is a validation panel down the right-hand side. Being honest, it was the single best resource we had during the whole process. It lists every task you still need to complete, and it is specific.
Two examples of what it caught for us. We wrote a description for the application first and only afterwards learned from the panel that the sentence has to start in a particular way, leading with the app name. We also learned there that a minimum number of real users need to be running your Zap before it can be published, three in our case, which is the kind of thing you would rather discover early than on submission day.
None of this is hidden. The full set of publishing requirements is written down and public, covering everything from prohibited categories to how your test account has to be set up. The panel is the same standard, applied to your integration, with the remaining items named. Read the requirements, then work the panel until it is empty.
The four stages of publishing
Build
Build is the default stage and where you make all the definitions. You can invite people, including your own test users, to try the integration while it sits here. When it holds together, you submit it for review.
Review
In review, a real person tests your integration. For them to do that you need to create an account for them and describe what they should do with it. One detail matters more than it looks: the test account email address has to be integration-testing@zapier.com, and the account needs to be non-expiring with whatever paid features the review requires already switched on.
Thanks to the validation panel, review was easy for us. We received two simple change requests, made both quickly, resubmitted, and had a response within the hour.
Beta
When Zapier first approves an integration, they publish it as Beta, and it stays there for 90 days. During that window they expect you to fix quickly anything users run into. Check that your technical contact details are current before you get here, because this is the period when someone may need to reach you.
Partnered
Partnered is the final stage. Your integration is fully published, and Zapier may do co-marketing with you from that point.
Publishing a Zapier app in 2026: what we would tell ourselves
Publishing a Zapier app is a real review against a written standard, and that is the best thing about it. The requirements are public, the validation panel names the exact thing that is blocking you, and human review comes back as specific points you can close rather than a verdict you have to interpret. We expected the ambiguity of a black box and got a checklist instead.
Our overall experience was positive, and for a new SaaS startup there is something worth having in being accepted onto a platform that size. If you have been putting it off because you assumed it meant months of bespoke API work, it very likely does not.
If you need a customer portal that works with Zapier, FormaPortal is our own tool. You can see everything a portal does out of the box, and how it is set up for different industries and use cases.