From Internal Workflows to Embedded Integrations
Zachary Kirby, co-founder of Vessel, on building the Vercel for integrations
The core split in integrations came from who the software was built for, not just what data it moved. Early leaders like Zapier, Workato, and Tray were designed so operations and product teams could drag together internal workflows without writing code, which made them great at moving data between apps inside one company. External integrations came later, by adapting that same workflow engine for customer facing use cases with added auth and embedding layers.
-
Internal integration products started with simple company workflows, like moving a lead from one internal tool to another, or syncing data between systems used by the same team. That meant less need for per customer OAuth handling, tenant isolation, or fine grained control over downstream API behavior.
-
That origin shaped the product. Workato is described as low code automation for enterprise app workflows, Tray as a drag and drop workflow builder, and Alloy draws the same line, iPaaS for internal process automation, embedded iPaaS for user facing integrations inside software products.
-
The strategic consequence is that newer platforms like Vessel, Prismatic, Paragon, and Alloy Embedded could enter by solving the parts workflow tools were not built around from day one, developer control, native UX, and customer specific edge cases. The market is moving from generic automation toward product grade integration infrastructure.
Going forward, the category keeps separating into two stacks. One stack serves internal automation for non technical operators. The other serves software companies that treat integrations like core product surface area. As more SaaS products win or lose deals on integration quality, developer first embedded and native platforms should keep taking share from generalized workflow tools in customer facing use cases.