- Prismatic's founders built hundreds of integrations before starting the company. That experience revealed the challenges of B2B integrations at scale, and no existing integration platform solved their specific use case when they searched for one.
- CNI lets developers build full integrations in TypeScript instead of just connectors. AI coding agents later made that same approach accessible to non-developers, and CNI usage became the primary way integrations are now built.
- Customer expectations expanded from "integration" to the broader idea of "extensibility." End users now expect to build their own custom workflows and interact with AI agents as primary users, not just work with pre-built connections to third-party systems.
- A modern embedded iPaaS provides four capabilities: productized integrations, custom integrations, embedded workflows, and an agent-ready server (to drive agentic interactions).
Why we started Prismatic
I've spent most of my career thinking about integrations in B2B software.
For the first 16 years, I scaled a company that provided mission-critical software to emergency dispatch, fire departments, and law enforcement. We built 600 integrations as part of our product and deployed them across hundreds of customers. As is common in software, those integrations extended our system and helped us serve our customers better. This led us to lean in hard, and we decided to become the most extensible product in our category. Over the next few years, we did exactly that. However, in the process, we discovered firsthand the many challenges that come with B2B software integrations at scale.
We envisioned an integration platform for software companies that would make what we were doing easier and more efficient. And we just assumed it existed. But after a lengthy search and deep evaluations with a couple of vendors, we decided that the integration platforms of the day solved a different problem than ours. So, disappointed, we chose to continue with the status quo.
A few years later, in 2019, after exiting my first company, I teamed back up with some people who had experienced all of this with me. We had seen firsthand the power of integrations and an extensible product, and we knew the software industry, and its end users, would benefit greatly from this becoming the new norm.
The missing platform for software companies
But it was clear that the problem wasn't software companies’ desire to provide extensible products; it was that those companies were experiencing the same friction points we had along the way. We just couldn't get out of our head that there should be a solution for our use case. And we started Prismatic.
We've now spent seven years building an amazing team at Prismatic, and together we've built the most complete integration platform ever assembled for B2B software companies.
This experience has taught us more than we ever dreamed about what's needed and how software extensibility can dramatically increase its value. It's recently led us to consider how our category has evolved and how it's best defined today.
It turns out that we've also redefined the modern embedded iPaaS.
Why software companies needed a different kind of iPaaS
When we started Prismatic, we had a simple, but strangely hard-to-explain thesis: an integration platform built specifically for software companies would lead to a very differently shaped solution than the existing iPaaS category, which comprised integration platforms meant for internal business use.
In our early years, I spent countless hours with industry experts, investors, and prospects explaining that we weren't building a "modern Boomi" or a "white-labeled Zapier." We were building something completely different. It would certainly have some overlap with iPaaS, but we were solving a different use case.
A dev-friendly, customer-facing platform required a different focus
The most important differences we saw between our focus and the traditional iPaaS focus were:
- By definition, software companies have developers. They are capable of using a more technical product and want to use it with a developer mindset rather than a power user mindset. This is fundamentally different than traditional (non-embedded) iPaaS, which companies use internally and are generally deployed by internal IT.
- Because the things software companies build are part of the products they provide to their customers, there's much less ability to accept rough edges and 95% solutions. Again, this contrasts sharply with traditional iPaaS, which, because it's used internally, requires less end-user polish.
- There's a whole set of problems to solve that are completely unrelated to the normal iPaaS use case. Things like multi-tenant (B2B2B) capabilities and UX for our customers' customers, like marketplaces and configuration experiences. These aren't at all contemplated by traditional iPaaS.
The foundation on which we built
These shaped our belief early on in a few key things:
- Building isn't the hardest part. Software developers at software companies can understand APIs and write scripts to move data around. Doing it at scale, in production-hardened ways , is what makes it difficult.
- Connectors, while useful, don't have anywhere near the proportion of overall value they do with iPaaS. Software companies tend to operate in vertical markets with niche solutions that will never make it into a connector library, no matter how large it is. And software developers are very eager to build bespoke connectors, as long as the developer experience is great.
- The overall solution has to provide a great developer experience and also a great experience for all the non-developers who will use the platform – from technical non-dev builders to DevOps to customer success.
- There always has to be a way to extend the platform with code. Software companies have customers to delight and can't let a platform keep them from getting where they need to go.
So we built and built and built. And found customers who shared our viewpoint. And found investors, whose own portfolio of many, many B2B software companies let them see that we were onto something.
Along the way we learned a lot.
The first definition of embedded iPaaS
Together with our contemporaries, we invented what, in 2020, was a modern vision for a new category: embedded iPaaS.
By 2022, a clear definition was established, originally codified by G2. Summarizing, it basically consisted of these requirements:
- Allow companies to connect their products to third-party applications for their customers
- Allow branding (white-labeling)
- Provide connectors to third-party applications
- Provide a marketplace and configuration experience for end users
- Allow companies to monitor and update integrations across their customer base centrally
- Provide an environment that runs integrations in an elastic and scalable way
- Provide a low-code integration builder
Several solutions, some built by startups and some built by legacy players, emerged. And a real category was formed.
Why the original definition wasn’t enough
But, like any new category, things continued to evolve quickly.
Our customers, all software companies, sensed and responded to changing expectations from their customers. As a result, they needed more from embedded iPaaS. And as we worked with more and larger customers, we kept discovering ways our solution could serve them better.
It was clear our vision, while still focused on the same general set of problems, needed to expand.
Integration development became code-native
As we listened to customers, it became apparent that our original insight about software companies having developers and therefore needing a specifically shaped solution was correct. We had built a platform that was tightly coupled to our customers' SDLC processes, was easy to script and programmatically control through our API, and provided a great TypeScript SDK for building connectors.
From connectors to full integrations
So we built what we called code-native integrations (CNI) at the end of 2023. A first in embedded iPaaS, this let developers build full integrations, not just connectors, with a TypeScript SDK. It provided a second way to build integrations on our platform, giving customers the flexibility to choose low-code or code while still accessing all the power of Prismatic.
While we built out and matured CNI as a first-class way to build in Prismatic, we saw some of our most technical customers start leaning into code over low-code. We had moved from Prismatic giving developers great ways to extend and embed it to being simply the most developer-focused embedded iPaaS ever built.
AI agents changed who could build
Then, along came AI coding agents. And all the optimization we had done to provide a great developer experience gave coding agents exactly the right tools. And suddenly, CNI was accessible not just to developers, but to everybody. We leaned hard into making sure our platform fully leveraged coding agents. And we watched users build faster than ever, often in mere hours, and CNI usage explode in just two quarters to become the dominant way integrations are built.
Today, we strongly believe that the majority of software companies are best served by an AI-enabled, code-native (code-first) building experience rather than the compromises that come with low-code.
Integrations became product extensibility
A second set of changes happened in parallel to the changes we brought to the building experience.
While integrations in their traditional form may have been sufficient in the 2010s, today's software end users need and expect more. Beyond out-of-the-box integrations, software companies need to let end users build custom workflows and enable their software to interact with AI agents as primary users.
This has expanded the need from simply "integration" to the much more complete idea of "extensibility".
Thanks to our partnership with forward-looking, ambitious customers across countless software markets and verticals, we've expanded our solution into something much more than we originally envisioned.
What software companies need from an extensibility platform
Today's end users need to customize the software they use around both their traditional and AI processes. This includes not just integrations to third-party systems, but also custom workflows to power in-product automations. This unlocks the next level of value their software can provide, but is difficult to get right.
To solve this problem, we've spent years, starting in 2023, building and maturing an incredibly powerful and flexible embedded workflow builder, giving software companies a simple way to provide an integration or workflow builder their customers can interact with directly. Fully AI-enabled, we've been able to make the end-user experience, especially for less technical end users, easier than we could have ever imagined possible. And our focus on developer control has given us the flexibility to ensure it feels native inside their products.
We've seen again and again how much power our customers unleash by letting end users customize product behavior themselves.
More recently, we've seen another change in end-user expectations for software: the need to support AI agents as first-class users. As our customers, and the software industry as a whole, wrestled with the right way to enable their end users' AI agents to interact with their products, it became clear that integrations and workflows would play an important part.
We quickly moved into this space, building ways for our customers to use productized and custom integrations and embedded workflows as the basis for tool calls from AI agents. Our MCP flow server, which we first released in 2025, is the tool layer for agent calls, providing ways to build deterministic workflows with structured inputs and predictable outputs.
Bringing it all together
The way all of this fits together crystallized for us early this year. We looked around and realized we'd built a platform much more complete than we originally envisioned. We had spent seven years listening to customers of all sizes and levels of sophistication. And we had, piece by piece, built what they told us, through words or actions, that they needed.
We realized that those customers were solving a broader set of problems with the platform than the embedded iPaaS category originally intended. And that the category, and most platforms it contains, aren't able to serve those customers well.
Overall, it became clear that the definition of embedded iPaaS, which we originally helped write, was now far too narrow for what software companies actually need today. End users have seen the impact integrations and extensibility can have, and they now think of this functionality as table stakes.
Today, we know that software companies have a broad set of needs to serve:
- Getting their customers' data in and out of the other applications their customers use and into their own product
- Enabling their customers to build workflows that fit the way they work and their specific use case
- Automating in-product events and actions that matter most to their customers
- Providing ways for their customers to interact with AI in their product
- Allowing for product customization on a per-customer basis
- Avoiding wrestling with third-party API changes, rate limiting, OAuth tokens, auth edge cases, and more plumbing across existing integrations
- Discovering (integration) production-breaking bugs proactively
- Knowing that it's all on top of infrastructure that's secure, highly reliable, and will scale elastically as necessary
Together, solving these problems can be thought of as making their products "extensible". And Prismatic has been fortunate to grow into a solution that solves them all.
An updated definition for embedded iPaaS
So it's time for a better, more modern definition for embedded iPaaS.
A modern embedded iPaaS is the foundation for product extensibility: productized integrations, custom integrations, embedded workflows, and agentic interactions, all on one core platform. It handles what breaks at scale, gives developers the tools to build fast, lets software companies provide their end users the ability to extend their products through embedded workflows, and gives AI agents the tools to take action across any system.
It does this via:
- Productized integrations – Pre-built, repeatable integrations shipped as product features. Customers self-serve from a native-feeling marketplace inside that product.
- Custom integrations – One-off integrations built to a single customer's specific requirements. Customers may or may not self-serve these from the marketplace.
- Embedded workflows – A low-code workflow designer embedded directly inside an product allows customers to build their own automations. These automations can define behavior within the product and can also interact with any combination of third-party applications.
- Agent-ready server – An MCP server that provides an easy way for AI functionality built as part of a product to act with integrations and customer-built workflows.
In addition to the expansion of the purpose and use cases of embedded iPaaS, it's become clear that a modern embedded iPaaS must provide tools for developers to build using their preferred tools rather than a low-code-only path.
These changes are all additive, meaning that the original definition is still important, just incomplete. Specifically, there are four crucial elements to a modern iPaaS, on top of the first definition:
- Allow companies to embed a workflow builder into their products that interacts with their product and third-party applications.
- Allow companies to expose integrations and workflows to AI agents.
- Allow fully custom customer-facing UX, going beyond normal white-labeling.
- Provide an AI-enabled, code-native (code-first) way to build integrations.
Overall, a modern embedded iPaaS is geared toward product extensibility, with integrations as only one part of how that's accomplished. Embedded workflow building becomes an equal part of the solution, and both workflows and integrations are made agent-ready. And everything is provided with better ways for technical users to build than iPaaS has traditionally delivered.
Product extensibility is the new standard
Over the last seven years, we've had the privilege of seeing up close as hundreds of customers have made their products more extensible, with integrations, end-user-facing workflow tools driving in-app automations, and first-class capabilities for AI agents. We've seen the impact this has for end users and the resulting increase in the perceived value of our customers' products as they solve more end-user problems.
This isn't a vision of where we're going or where we think our category should go. It's simply what we've built and the way we see customers using Prismatic. We've built a more complete solution than we originally envisioned, shaped by seven years of experience with customers, the market, and lessons learned along the way.
Along the way, a clearer definition of a modern embedded iPaaS has emerged.
With that definition in mind, we're thrilled to keep partnering with forward-looking software companies and help them delight their customers with the extensible products they expect.
