Integration Count Is a Vanity Metric Now

For most of the last decade, automation platforms competed on a single number and put it on the homepage. 6,000+ integrations. 400+ connectors. Connect to everything. The number was the moat. If a competitor had Salesforce and you didn't, you lost the deal, so everyone raced to grow the catalog, and the catalog size became the scoreboard.

Flomorphic just shipped a feature built on the opposite bet: that number stopped being worth counting. Not because integrations don't matter — they matter more than ever — but because the thing that made a catalog expensive to build has been unbundled and handed to a broker. Once that happens, "how many connectors did you pre-build?" measures the wrong thing, the way "how many fonts ship with the OS" stopped being how you pick a computer.

The feature is a new item in the main menu called Connect, and this piece is about what it is, what it quietly assumes, and why that assumption makes the integration-count race a race worth losing.

The half of an integration nobody demos

Open any connector's source and split it in two.

The first half is the interesting-sounding part: call the API. Send a message, read a row, create an issue, list the files. This half is genuinely small. Most SaaS APIs are a REST endpoint and a JSON body; a competent developer wires one up in an afternoon, and a coding agent does it in a minute.

The second half is the part that never makes the demo, because it has no visible output. It's auth. Registering an OAuth app. Handling the three-legged consent redirect. Storing the access token and the refresh token somewhere encrypted. Refreshing the token before it expires and retrying the call that failed because it expired mid-request. Scoping permissions. Rotating a leaked secret. Doing all of that again, differently, for the next provider, because every vendor's OAuth dialect is its own small dialect of pain.

That second half is where the cost of a connector actually lives. It's why a catalog of 400 integrations represents years of work and a maintenance burden that never ends — not because calling 400 APIs is hard, but because safely holding credentials for 400 services is hard, and stays hard after you ship. The API call is the thing you were trying to do. The auth is the tax you paid to be allowed to do it, over and over, forever.

The moat was never the connectors. It was the credential vault and the OAuth machinery behind them. And that is exactly the thing Connect declines to build.

What Connect is

Add a menu item called Connect to Flomorphic and open it for the first time. It doesn't ask you to configure a hundred services one by one. It offers you a single thing to set up: an open-connector connection, with the suggestion to use the OOMOL cloud.

open-connector is an open-source auth gateway — its own description is "connecting 1,000+ SaaS providers to AI agents." That phrase is the whole point. It is not another automation tool competing on connector count; it is the layer underneath connector count. Its entire job is the expensive half above: it centralizes credential management, runs the OAuth handshake, refreshes tokens, and normalizes the APIs, for a catalog on the order of a thousand-plus platforms — Gmail and the rest of Google's services, Telegram, WhatsApp, Notion, GitHub, and a long tail after that.

The OOMOL cloud is open-connector's hosted runtime — the site you're pointed to when you click through from Connect. The workflow there is the one an auth gateway implies:

1. You make an OOMOL account.
2. Inside it, you log in to each platform you want — once, through OOMOL's consent flow. That's the OAuth dance, done in the place built to do it, not re-implemented inside Flomorphic.
3. OOMOL now holds those authorized connections and hands you an API token.
4. You paste that token into Connect.

From that moment, Flomorphic doesn't hold anyone's Google password or Telegram session. It holds one token to a gateway that holds the rest — and the gateway is the thing whose full-time job is holding them safely. The credential-vault problem didn't get solved inside Flomorphic. It got delegated to the component whose only reason to exist is solving it.

Authorize once, reuse everywhere

There's a second-order effect here that's easy to skate past, and it's the part that compounds.

The accounts you connect in OOMOL aren't bound to Flomorphic. They're bound to your OOMOL account. open-connector speaks SDK, CLI, MCP, HTTP, and OpenAPI — so the Gmail you authorized to use in a Flomorphic flow is the same authorized Gmail available to any other tool you point at the same gateway. You did the consent screen once, and it's now a reusable asset across every platform that speaks open-connector, Flomorphic included.

That inverts the usual arrangement. Normally your integrations are trapped inside the tool that holds them: authorize Slack in Zapier and that authorization is Zapier's, gone the day you leave. Here the authorization lives in a broker you own, and the tools are clients of it. Flomorphic becomes one consumer of your connected accounts rather than the owner of them. Leaving, adding a second tool, or self-hosting the gateway later doesn't cost you the consent screens again.

The other half got cheap too

So auth is brokered. That handles the expensive half. But an authorized token sitting in Connect isn't yet a node you can drop on the canvas — someone still has to turn "I can reach Gmail" into "there's a Gmail node in my flow palette with a proper form." That's the first half, the API-call half. And the honest thing to say is: Flomorphic does not yet have a plugin for all thousand-plus open-connector services. Nobody does.

That used to be the sentence that killed the pitch. It isn't anymore, and the reason is the whole argument of this piece.

Turning an authorized service into a native Flomorphic node is a plugin — a small program that speaks the runtime's inflowv1 protocol, carries its own configuration form, and installs through a menu into the node palette like a browser extension, no fork and no redeploy. Writing one used to mean learning a wire protocol. Now the SDK ships a cookbook and a SKILL.md — an agent skill that teaches a coding agent the SDK's real API and its gotchas — so you point Claude Code at the skill, hand it the service's OpenAPI, and get a correct, working plugin back. And crucially, that plugin no longer has to carry the auth: it calls open-connector with the token, and the gateway handles the credentials. The plugin author writes the fun half and skips the tax.

Line the two halves up:

• Auth — the hard, permanent, per-provider half — is done once, in a broker built for it, reusable across tools.
• The node — the API-call half — is a short, guided, agent-written plugin against a normalized gateway, with no credentials to manage inside it.

When both halves are cheap, the pre-built catalog stops being a moat and starts being a convenience. Whether Flomorphic ships with 100 native nodes or 400 no longer decides anything, because the 401st is an afternoon, and the auth behind it was never yours to build.

And you don't hunt for those nodes one at a time. When you install Flomorphic, the plugin catalog is the front door to what you actually need — a single index you install from, on demand, for the services your flows touch. You don't pull a thousand nodes into the box and hope; you pull the handful your work uses, when it uses them. The catalog is the shipping mechanism, and open-connector is the authorization underneath it, so "does it have X?" collapses into "install X" for the common case and "have an agent build X" for the rare one.

What we actually bet on

Notice what the bet is not. It isn't "we'll out-ship the catalog race." We deliberately walked away from that race. The bet is on two things underneath it.

The first bet is the plugin itself — and how much more it is than an adapter. In most tools an "integration" is a thin input/output shim: hand it arguments, get a result, done. A Flomorphic plugin is the opposite of thin. It's a full-featured extension point that speaks the inflowv1 protocol, ships its own UI builder so it renders a real configuration form on the canvas without its author writing any frontend, runs anywhere the runtime runs — cloud, laptop, air-gapped — and, the part that changes everything, lives in the heart of the runtime rather than at its edge. A plugin isn't called by the flow across a boundary; it's inside the flow. It reads and writes the running context by JSON path mid-execution, steers the flow's own routing with the same tag mechanism every built-in node uses, holds long-lived connections, and streams its progress onto the diagram. That is a categorically bigger thing than "an integration." It's a native, governed participant. So when we say plugins make integration count irrelevant, it's not because plugins are a cheap way to fake connectors — it's because a plugin is a more powerful unit than the connector it replaces.

The second bet is the infrastructure to reach anything — open-connector. Rather than pre-building a vault for a thousand services, we bet on the layer whose entire job is authorized access to a thousand services, and made Connect a first-class door to it. One bet is depth (the plugin, all the way into the runtime's core); the other is reach (the gateway, out to every platform). Between them, the pre-built catalog is a convenience layered on top, not the foundation anyone's standing on.

Why the number stopped scoring

Put it plainly, because it's the thesis and it deserves to be blunt: in the AI era, having 100 or 400 pre-built integrations is not a score.

It was a score when both halves were expensive — when every new connector meant a developer learning yet another OAuth dialect and hand-writing the client, so a big catalog was real, hard-won evidence of years of labor you couldn't easily match. The catalog size was a proxy for "we did the painful work so you don't have to," and that proxy was fair.

Two things broke the proxy at once. A credential broker like open-connector collapsed the auth half from per-provider engineering to one consent screen in a gateway. And coding agents collapsed the client half from learn-the-protocol engineering to describe-what-you-want. Neither alone would be enough — a broker with no easy way to build nodes still leaves you writing plugins by hand; agent-written plugins that each have to re-solve OAuth still drown in the tax. Together they take the two things that made a catalog expensive and make both of them cheap. What's left of "we have 400 integrations" is a head start, not a wall.

There's a second, quieter reason the number is a bad target: most of any thousand-connector catalog is dead weight for any given user. No team touches a thousand services, or a hundred. Ship a thousand and you've spent your engineering budget building, testing, and forever maintaining connectors that the overwhelming majority of your users will never open — a catalog optimized to look impressive on a comparison page, not to be used. The honest question isn't "why don't you have a thousand integrations?" It's "why would we ship a thousand when half of them are useless to everyone and the whole of them is useless to each person?" Better to make the right one a one-line install and the missing one an afternoon than to carry a museum of connectors nobody asked for.

This is the same instinct as the rest of the platform, pointed at integrations. Flomorphic already argues you extend it like a browser extension instead of forking it, and that you should reach external systems over MCP rather than coupling to them. Connect is the third leg: the platform doesn't try to own a giant credential vault, it brokers to one — and lets the ecosystem, with an agent's help, fill in the nodes on demand. Owning the vault was the old moat. Refusing to own it is the new position.

The self-hosted future, already anticipated

One reasonable objection to all of this is trust: a broker holding your credentials is a broker holding your credentials, and the OOMOL cloud is somebody else's runtime. For a demo or a personal flow that's fine; for a regulated shop it's a conversation.

open-connector answers that by being open-source and self-hostable — it deploys to local Docker or Node, to Fly.io, to Cloudflare Workers, and OOMOL's cloud is just the managed option, not the only one. So the credential gateway can live inside your own walls, on infrastructure you control, and Connect still talks to it the same way — it's the same protocol whether the gateway is OOMOL's or yours.

That's why the Add Connection flow is built with more than the cloud in mind. Pointing Connect at the OOMOL cloud is the fastest path and the one the first-run screen suggests, but the connection is to an open-connector endpoint, and that endpoint doesn't have to be OOMOL's. A likely next step is a self-hosted open-connector deployed specifically for a Flomorphic platform — the same authorize-once, reuse-everywhere mechanics, with the vault on your side of the line. The feature was shaped so that when that lands, it's another option in Add Connection, not a rewrite. This connects to the broader argument that the infrastructure holding your organization's sensitive material should be a first-class, governed participant in your flows — not a thing you rent and hope about.

Seeing it move

Words undersell how small the loop actually is, so this piece comes with a screen recording of the real thing: opening Connect for the first time, following the suggestion to the OOMOL cloud, authorizing a platform there, copying the API token back into Add Connection, and then dropping the now-authorized service into a flow as a node. The point the recording makes better than any paragraph is how little of it is setup — most of the clicks are the OAuth consent screens you'd have to click anyway, and the Flomorphic side is a paste and a drag.

Watch for the moment the token lands and the service is simply available — no vault configured, no secrets pasted into a node, no OAuth app registered. That absence is the feature.

The one-paragraph version

Automation platforms spent a decade competing on integration count, and the count was a fair proxy for hard work — because every connector cost you two expensive halves: writing the API client, and, far worse, building and forever maintaining the OAuth and credential machinery behind it. Flomorphic's new Connect menu item bets that proxy is dead. It brokers the expensive half to open-connector, an open-source auth gateway (hosted as the OOMOL cloud, or self-hostable in your own walls) whose entire job is holding credentials for 1,000-plus SaaS platforms: you authorize each service once in your OOMOL account, reusably across every tool, and hand Flomorphic a single API token instead of a vault of secrets. The other half — turning an authorized service into a native palette node — is now a short plugin an agent writes for you, calling the gateway with the token so it never touches the credentials at all, and installed from the catalog on demand rather than shipped by the thousand. We didn't bet on out-shipping the catalog race; we walked away from it. We bet on two things instead: a plugin that's far more than an I/O shim — protocol, its own UI builder, runs anywhere, and lives in the heart of the runtime touching flow context and routing, not just at its edge — and the infrastructure to reach anything through open-connector. Depth and reach. Because there's no reason to ship a thousand connectors when half are useless to everyone and the whole is useless to each person. Authorize once, let an agent build the node, and stop counting.

Connect to it: open-connector — github.com/oomol-lab/open-connector, OOMOL cloud — oomol.com, and the self-hosting guide.

Plugin SDK (cookbook + SKILL.md): github.com/Inflowenger/go-plugin-sdk

Plugin catalog: github.com/Inflowenger/plugin-catalog

Concepts and docs: inflowenger.com/flomorphic

New here? Start with The Model Proposes, the Graph Decides, then You Extend Flomorphic the Way You Install a Browser Extension for how an authorized service becomes a node.