Connectors Are the Commodity

We just open-sourced Prismatic's entire connector library under the Apache-2.0 license. Not because our connectors are what makes Prismatic valuable. They aren't. Here's why connector count and "open" badges are the wrong things to evaluate, and what to look at instead.

This week, we made the source for every application connector and data platform component that Prismatic ships public on GitHub. Anyone can read it, fork it, and build on it.

If you've spent any time evaluating integration platforms, that might sound like a big concession. Connectors are supposed to be the asset. Vendors put the number on the homepage (1,200+ connectors!) and treat an open connector library as a trust signal worth a press release.

We see it differently. We open-sourced our connectors because we don't think they're what makes a platform worth buying. Building a connector is the easy part, and it's getting easier every month.

Let me explain what I mean, and what matters when you're choosing an embedded iPaaS today.

First, the vocabulary

An embedded iPaaS (integration platform as a service) is software that lets a B2B SaaS company build, deploy, and manage product integrations for its own customers, under its own brand, inside its own product. It's distinct from internal automation tools like Zapier or Make. An embedded iPaaS runs your customer-facing integrations (not back-office workflows) at scale.

A connector (aka component) is a reusable piece of code that communicates with a specific third-party API: Salesforce, NetSuite, HubSpot, a database, or a file store. It handles authentication and exposes a set of actions and triggers you can drop into an integration.

Connectors matter. You need good ones. But "needing good connectors" and "connectors being the differentiator" are two very different claims, and vendors routinely conflate them.

The two metrics the category leads with, and why they no longer matter

Watch how integration platforms market themselves, and you'll see the same two talking points appear regularly:

• Library size. We have more connectors than they do. It's an easy number to put on a slide and an easy number to fixate on. But raw count tells you almost nothing about whether the specific connector you need is any good, whether it covers the endpoints your customers actually use, or whether it's been updated since it shipped. A library of 1,200 connectors where the three you need are shallow or stale is worse than a library of 200 where they're well-suited for the task and kept up to date. Count is a vanity metric dressed up as coverage.
• Openness. Our connectors are open source; look how transparent we are. Transparency is good, and customers should be able to see the code that's running in their integrations. But notice what's being implied: that opening the connector layer is a meaningful act of generosity, because the connectors are valuable IP. That premise is exactly backward. We are comfortable opening ours up because the connector layer isn't where the value lives.

Both of these talking points work for the same reason: they appear straightforward. A number is easy to compare, and "open source" is easy to feel good about, while the things that determine whether your integration program succeeds are harder to reduce to a badge. And AI has made both signals weaker still.

The biggest shift in the category for 2026 isn't a longer list of connectors. It's that integrations and the connectors behind them are increasingly AI-generated. Point a capable model at an API's docs and a clear SDK, and it will scaffold a working connector with auth, actions, and triggers. Writing a connector is now something an AI assistant can do in an afternoon, and the marginal cost of "one more connector" is approaching zero. When this is true, a giant pre-built library stops being a moat and starts being table stakes – table stakes that anyone, including you, can now meet on demand.

This is also why open-sourcing our connectors is a forward move, not a defensive one. Real, production-grade code is the best possible foundation for AI-assisted development. Our own AI tooling, Prismatic Skills, can generate custom components and integrations that match how we build our components, because it can reference the real implementations rather than infer patterns from documentation. Open-source connectors make every AI-generated connector better, ours and yours alike.

When connectors become something you can generate, the durable value moves up the stack to everything that happens after the connector exists.

So what is the secret sauce?

Building a connector is quick work. Running thousands of customer-specific integrations in production, for years, without overwhelming your engineering team: that's the hard part. That's the platform. It's where we've spent the better part of a decade, and it's what's worth scrutinizing in any evaluation:

• Two real ways to build, both accelerated by AI. A low-code designer non-developers can use, and a code-native path where your engineers build integrations as code in their own IDEs, with version control and CI/CD. AI coding assistants speed up both approaches by scaffolding connectors and integrations against the SDK. However, most platforms support one approach well and bolt on the other.
• Deployment and configuration at scale. Turning one integration into hundreds of customer-specific instances (each with its own config, credentials, and field mappings) without re-creating each one by hand.
• An embedded marketplace. A native, self-serve integration catalog that your customers use inside your product, so activating an integration doesn't require a support ticket.
• Operations: logging, monitoring, alerting. When a customer's integration breaks at 2 AM, can you identify the cause and fix it before they notice? This is where embedded integration programs live or die.
• Versioning and change management. Shipping an update to an integration without causing issues for customers running the previous version.

None of that fits in a "we have N connectors" headline. All of it is what determines whether your integration program is an asset or a liability a year from now.

Then why open-source them at all?

If connectors aren't the moat, why bother making them public? Because doing so is useful to the people building on Prismatic.

Customers kept asking us for the same things. They wanted to take one of our connectors that was almost right for their use case and tweak it (add an action, change a behavior) instead of rebuilding it from scratch. They wanted to see how a well-built component is structured, as a reference for the custom ones they were writing. And increasingly, they wanted their AI tooling to learn from real examples rather than guesses.

Open-sourcing answers all three:

• Fork and customize. Take our Salesforce or NetSuite connector, extend it to meet your customers' needs, and publish it as your custom component.
• A reference for what "good" looks like. Every connector we ship is now a working example of how to build on the Prismatic SDK.
• Better AI-generated components. Production code is the foundation that enables accurate AI-assisted component-building.

We can open this layer up because we're confident about where our value sits. That's the opposite of a concession. It's a statement of what we think matters, and what doesn't.