3 models for product integrations: a choice between control and velocity

Building B2B SaaS integrations is a trap. What starts as a simple Jira ticket to "add a Salesforce sync" inevitably mutates into a massive, ongoing maintenance burden that drains your engineering resources.

While the tooling ecosystem has exploded, there are effectively only three architectural patterns for building product integrations. Each represents a brutal trade-off between engineering control, development velocity, and long-term maintenance debt.

The 3 core models for product integrations are:

• Direct Integrations: Writing custom code to connect directly to each external system's API.
• The Unified API: Building to a single abstraction layer that normalizes data across hundreds of disparate systems.
• Embedded iPaaS: Embedding a third-party visual workflow builder into your app for custom, drag-and-drop logic.

Let's break down the reality of each approach, the hidden costs, and how the architecture is evolving to bridge the gaps.

1. Direct Integrations (The "Build It In-House" Approach)

This is the traditional approach. Your engineering team writes custom code to connect to each external system—building one client for Salesforce, another for HubSpot, and another for Pipedrive.

How it works: Your team owns the entire stack. You manage OAuth2 flows, token rotation, data mapping, retry logic, rate limit backoffs, and API versioning.

The Reality: This model works fine for your first two or three integrations. But our customer data—backed by wider industry research—shows that most SaaS teams hit a breaking point at 10–15 integrations. Beyond this threshold, the maintenance burden cannibalizes core product development.

• The hidden cost: Industry estimates show that maintaining a single custom integration costs between $50,000 and $150,000 annually. This accounts for engineering time, QA, monitoring, and dealing with undocumented API changes.
• The resource drain: Our data indicates that 1 Full-Time Engineer (FTE) is required just to maintain every 5 to 10 active integrations. If you plan to support 50+ integrations, building directly means hiring a dedicated sub-team solely for upkeep.
• The debugging nightmare: When a third-party API randomly breaks, it routinely burns 5–6 hours of a developer's day just isolating the issue, often requiring support tickets to the underlying platform.

2. The Unified API (The "Write Once, Connect Many" Approach)

A Unified API acts as an abstraction layer, normalizing the data models of dozens of disparate systems into a single, standardized interface. (Key players: Truto, Merge, Apideck).

How it works: You build exactly one integration to the Unified API provider. The provider handles the downstream complexity of normalizing data schemas, managing auth tokens, and maintaining connectivity across hundreds of distinct connectors.

The Reality: Unified APIs are built for scale. They allow you to ship 50 integrations in a single sprint instead of a single year.

• The latency myth: A common objection from engineers is that adding a middleware layer slows down data transfer. In reality, modern Unified APIs are highly optimized proxies. Internal benchmarks at Truto show the average overhead is just 30 to 100ms—an imperceptible delay to the end-user.
• Infrastructure resilience: It’s not just about connecting; it’s about staying connected. In an analysis of 100 million API calls, we found that 5% of failures were environmental (rate limits, expired auth tokens, 502 Bad Gateway timeouts). A Unified API handles these transient failures automatically via exponential backoff, preventing them from becoming support tickets.
• The Limitation: The classic trade-off of a Unified API is the "lowest common denominator" problem. Because the API normalizes data, you historically lose access to highly specific custom fields or edge-case endpoints that exist in the underlying platform.

We could maybe build 50 integrations a year… or we can do it in a couple of weeks [with Truto]. We needed a spike and one engineer for a sprint to do 50 this past sprint.
— Annie Gregory, Principal Product Manager at Thoropass

3. Embedded iPaaS (The "Workflow Automation" Approach)

Embedded iPaaS (Integration Platform as a Service) is essentially a white-labeled workflow automation tool embedded directly into your application. (Key players: Workato, Tray.io, Paragon).

How it works: Connectors are pre-built, and integration logic is defined via a visual, drag-and-drop UI. The workflows run on the iPaaS provider's serverless infrastructure.

The Reality: Embedded iPaaS is built for bespoke, low-volume implementations where every customer needs a slightly different logic flow.

• Best for non-technical control: If your product managers or your end-users need to build custom triggers and actions without touching code, this is the right path.
• The UI problem: iPaaS often struggles to feel native. It forces third-party UI elements (like an iframe workflow builder) into your app, which can degrade the user experience.
• The developer experience (DX) nightmare: As integrations get more complex, visual workflow builders become a liability. Experienced engineers hate debugging spaghetti logic in a drag-and-drop UI; they want to debug via code, logs, and stack traces.

As one engineer at a Series-B SaaS told us: "Once a workflow gets deep enough in an iPaaS, I would rather just build it directly in code."

The Evolution: Programmable Unified APIs

Historically, engineering teams had to choose: take the Unified API for scale and lose flexibility, or take the Embedded iPaaS for flexibility and lose the developer experience.

Based on brutal feedback from scaling engineering teams, the architecture has evolved. Unified APIs are now optimizing for depth, creating a hybrid model: The Programmable Unified API.

At Truto, we built our architecture specifically to eliminate the "lowest common denominator" limitation:

• Proxy APIs (Passthrough): We provide a direct passthrough to the underlying API. If you need a hyper-specific custom field in Salesforce that isn't in the unified model, you can query it directly through Truto. You get the flexibility of a direct integration while we still handle the boring parts (auth, token rotation, pagination).
• Declarative Customization: Truto allows for complete customization of the unified mapping. You can build entirely new unified models on the fly, tailoring the abstraction to your exact database schema.
• Data Mapping UI: We provide RapidForm, allowing you to generate native-feeling, on-the-fly data mapping UIs for your users without forcing them into an iPaaS workflow builder.
• Truly Real-Time: Most unified APIs (like Merge) cache customer data on their servers. This introduces major security liabilities and creates a "sync gap" where users see stale data. Truto uses a real-time passthrough architecture—meaning zero-second data drift and no third-party data storage.

Summary: Which Model Wins?

Choosing your integration architecture is a one-way door decision. If you optimize purely for control today, you will drown in maintenance debt tomorrow. Choose the model that gives your engineering team the highest leverage.