What an Automation Marketplace Actually Is
When a workflow automation platform launches a marketplace, it is doing two things at once: extending its surface area without hiring more engineers, and creating a distribution channel that generates revenue from third-party developers. The user-facing pitch is "find an app that does exactly what you need." The platform-side reality is closer to "let other people build the long tail we can't justify staffing."
That is not cynical — it is just the economics. Zapier, Make (formerly Integromat), n8n, and similar tools all run some version of this model. The platform sets the technical standards (authentication patterns, trigger/action schemas, rate-limit rules), opens a developer program, and then reviews submissions before listing them publicly. What the user sees as a tidy row of app icons is the output of that review pipeline.
Understanding this structure matters because it tells you who is responsible for what when something breaks.
The Three Tiers of Apps in Any Marketplace
Most automation marketplaces quietly operate on a tiered model, even if they don't advertise it.
Tier 1 — Native apps: Built and maintained by the platform itself. These get priority support, survive platform updates, and are the safest long-term bets. Slack, Google Sheets, and Gmail integrations on most major platforms fall here.
Tier 2 — Verified third-party apps: Built by the SaaS vendor whose product the app connects to (e.g., HubSpot building its own Zapier connector). These are usually well-maintained because the vendor has a business incentive to keep the integration working. API changes get patched quickly because the same team controls both ends.
Tier 3 — Community or independent apps: Built by individual developers or agencies, often to scratch their own itch and then published. Quality varies enormously. Some are excellent and actively maintained. Many are abandoned six months after launch. The platform's review process caught the initial submission, but ongoing maintenance is entirely up to the original developer.
When you install an app, you are almost never told which tier it belongs to. You have to infer it from the publisher name, the last-updated date, and the support response rate.
How Revenue and Incentives Flow
Free apps dominate most automation marketplaces in raw count, but the economics underneath are not as simple as "free means no cost."
For paid apps, platforms typically take a 20–30% revenue share from the developer. This creates a selection pressure: developers building paid apps on a marketplace need enough volume to justify the cut. That often means targeting popular use cases — which is good for discoverability but means niche workflows are underserved or served by lower-quality free apps.
For free apps, the developer's incentive is usually lead generation. An agency publishes a free Notion-to-Airtable sync app because it puts them in front of businesses that might hire them for custom automation work. That is a legitimate model, but it means the app's maintenance lifecycle is tied to the agency's business development calendar, not to your operational needs.
Platforms that charge per-task or per-operation (Zapier's task-based pricing is the canonical example) have an additional incentive structure worth understanding: they make more money when your automations run more steps. This is not inherently bad, but it does mean the platform's design defaults may not optimize for the leanest possible workflow.
What "Installed" Actually Means
Installing a marketplace app is not the same as installing software on your computer. When you click "Install" in an automation marketplace, you are typically doing three things:
- Granting OAuth permissions — authorizing the platform to act on your behalf on the connected service (read your emails, post to your social accounts, update your CRM records).
- Pulling in a pre-built template — loading a workflow configuration that the app developer designed, which you then customize.
- Accepting a dependency — your workflow now relies on the app developer keeping their connector schema aligned with the underlying service's API.
That third point is where most marketplace apps eventually fail. When Shopify updates its API version and deprecates old endpoints, every third-party Shopify connector built against the old version breaks simultaneously. Tier 1 and Tier 2 apps get patched quickly. Tier 3 apps may sit broken for weeks or permanently.
This is one of the structural problems that newer automation approaches try to solve differently. Platforms like Koira sidestep the API dependency entirely by operating directly on the browser interface — the same way a human would — which means the automation doesn't break when an API version changes, because it was never using the API to begin with. The tradeoff is different (browser-based automation has its own constraints), but for tasks where no stable API exists or where API access requires an expensive plan tier, it's a meaningful architectural distinction.
How Curation Actually Works (and Where It Falls Short)
Every major automation marketplace has a review process. What that review typically checks:
- Authentication security — does the app handle credentials safely?
- Schema compliance — does the trigger/action structure match the platform's technical spec?
- Basic functionality — does the app do what it says in the listing?
What the review almost never checks:
- Long-term maintenance commitment — will the developer update this when the underlying service changes?
- Edge-case handling — what happens when a required field is empty, or the connected service returns an error?
- Data handling practices — what does the developer do with the data flowing through their connector?
The result is that a marketplace listing is a snapshot of quality at the time of approval. It is not a guarantee of current quality. A four-star app that was last updated eighteen months ago may be actively broken for workflows that touch any service that has changed its API since then.
What to Actually Look For Before Installing
When evaluating a marketplace app for a business-critical workflow, ignore the star rating as your primary signal. Use these instead:
Last updated date. If the app hasn't been updated in over a year and the underlying service has released API updates in that period, treat it as a yellow flag. Two years without an update on a connected service that ships frequently is a red flag.
Publisher identity. Is the publisher the same company that makes the product being integrated? If yes, that's a Tier 2 app — much safer. If it's an individual developer name or an agency, understand that your workflow depends on that person's continued interest.
Support channel. Does the listing link to a real support channel — a GitHub repo with open issues, a help desk, a community forum? An app with no visible support path is an app that will leave you stranded when it breaks.
Install count in context. High install counts indicate the app is popular, not that it currently works. Low install counts on a recently published app from a credible publisher can actually be a better signal than high install counts on a stale app.
Documentation depth. Well-maintained apps have detailed documentation. Apps that are coasting on their initial launch typically have a one-paragraph description and nothing else.
The Lock-In Question
Marketplace ecosystems create lock-in that is easy to underestimate at the start. Once you have built twenty workflows on a specific platform using specific marketplace apps, migrating to a different platform means rebuilding all of them — often from scratch, because workflow configurations are not portable between platforms.
This is worth thinking about before you go deep. The platforms that have the richest marketplaces (Zapier, Make) also have the strongest lock-in because the workflow logic lives in their proprietary format. Open-source platforms like n8n reduce this risk because you can self-host and export your workflow JSON, but the tradeoff is operational overhead.
For owner-operators, the practical answer is: don't let your most critical business processes depend on a single Tier 3 marketplace app. If a workflow is genuinely business-critical — order confirmation emails, booking confirmations, invoice generation — either build it on a Tier 1/Tier 2 app, or make sure you have a manual fallback you can activate in under an hour.
How Marketplace Apps Get Deprecated
Apps get removed from marketplaces for a few common reasons: the developer stops maintaining them, the underlying service shuts down or changes its API in a breaking way, or the platform enforces a new security standard the app doesn't meet.
When an app is deprecated, the platform's typical behavior is to leave existing workflows using that app in a broken state and notify users via email. You are then responsible for finding an alternative and rebuilding. This is not a theoretical risk — it happens regularly on every major platform.
The mitigation is to audit your active workflows quarterly. Check that every app in use has been updated in the last six months. Flag any that haven't for manual review. It takes about twenty minutes and will save you the operational scramble of discovering a broken workflow when a customer is waiting on the other end.
What the Next Generation of Automation Marketplaces Looks Like
The current marketplace model — curate at submission, hope for ongoing maintenance — is showing its age. A few structural shifts are underway.
First, platforms are moving toward automated compatibility testing: running a test suite against every listed app on a regular cadence and flagging or removing apps that fail. This shifts the maintenance burden back to the developer in a more accountable way.
Second, AI-generated connectors are starting to appear, where the platform generates a connector on-the-fly from a service's API documentation rather than relying on a human developer to build and maintain it. This solves the Tier 3 maintenance problem but introduces new questions about reliability and edge-case handling.
Third, some platforms are moving away from the API-connector model entirely for tasks where the target service either doesn't have an API or locks it behind expensive enterprise tiers. Browser-native automation — where the software operates the actual web interface — is increasingly viable as a complement to traditional API-based integration, especially for the kind of operational busywork that owner-operators do every day.
The marketplace model will keep evolving. What won't change is the underlying question you should ask before installing anything: who is responsible for keeping this working, and what happens to my business when they stop?
