Integrations as Product Control

Diving deeper into

Former Zapier partner on Zapier's commoditization of SaaS

Interview
we didn't want to put JavaScript code running in our context that we didn't have control over.
Analyzed 6 sources

This reveals that the fight over integrations was really a fight over product control. Embedding a partner owned script inside the core app meant giving another company code execution inside the user experience, plus influence over what integrations users saw and how they set them up. For a SaaS company, that touches security review, reliability, UI consistency, data visibility, and the risk of turning the product into one interchangeable tool inside a larger marketplace.

  • The partner program was not just an API connection. It also pushed companies to place a Zapier widget inside their app so users could browse downstream actions and templates. That moves integration discovery and setup into a third party controlled layer, not the host product’s own interface.
  • Running outside JavaScript inside a signed in app session is a real technical and governance issue. That code can affect page behavior, performance, and what user data is exposed in the browser, which is why embedded integration vendors now emphasize white labeled flows, server side calls, and isolated auth models.
  • This pressure helped create a new category of embedded integration platforms like Tray and Paragon. Their pitch is simple, let the SaaS company keep the integration UI inside its own product, decide which workflows appear, and capture usage data without sending users into a broad neutral marketplace.

Going forward, more software companies will treat integrations as part of the product, not a plug in they hand off to a marketplace. The winners will be the platforms that let a product team ship many integrations fast while still keeping the interface, telemetry, and customer relationship inside their own walls.