Integration Infrastructure vs Unified APIs vs Embedded iPaaS: How to Choose the Right Layer for Native Product Integrations

Introduction

Every SaaS team that ships customer-facing integrations eventually has to make a category decision. There are three serious options on the market today: Integration Infrastructure, Unified APIs, and Embedded iPaaS. They look superficially similar from the outside (each promises to make integrations easier), but they target fundamentally different problems, ship with different tradeoffs, and break in different ways at scale.

Picking the wrong category is one of the more expensive mistakes a product team can make. The wrong choice does not announce itself in the first month; it shows up six to twelve months in, when you are trying to onboard a new system, satisfy a customer's permission requirements, support custom objects you never modeled, or move past read-only into bi-directional writes that your customers actually trust. By then, the cost of switching is substantial, and the integration team you wanted to keep small has grown to compensate for what the platform does not give you.

This post is a working framework for picking between the three categories. It defines what each one is built for, where each one excels, and where each one stops being useful. It is opinionated, written from a vendor's perspective (Ampersand operates in the Integration Infrastructure category), but the underlying analysis is something we have walked dozens of teams through and is grounded in how each architecture actually behaves in production.

The Three Categories, Plainly Defined

Before getting into the comparison, it is worth being precise about what each category is, because the marketing language overlaps in unhelpful ways.

Unified APIs are services like Merge, Finch, Apideck, and Kombo. They abstract a category of SaaS systems (HRIS, ATS, accounting, CRM, or payroll) behind a single API. You write to one schema; they translate to whichever underlying vendor your customer has connected. The pitch is "one integration, many systems." They are most useful when the data model in a category is fairly standard, when read access is the primary use case, and when depth into any one vendor's quirks is not a hard requirement.

Embedded iPaaS are services like Paragon, Workato Embedded, Prismatic, and Tray Embedded. They give you a workflow builder and a runtime, often with a UI you can embed in your product so end users (or your team) can configure integrations through clicks rather than code. They evolved out of the broader iPaaS category that built tools like Workato Cloud and Boomi for internal IT use, then repackaged the runtime for SaaS companies who wanted to ship integrations to customers. The pitch is "drag and drop integration flows that your customers can configure themselves."

Integration Infrastructure is the category Ampersand sits in. It is integration-as-code: a declarative configuration (in our case, YAML), a managed runtime that handles auth, scheduled reads, on-demand reads and writes, dynamic field mapping, custom objects, and bulk write optimization, and a deployment model that fits how engineering teams actually ship software (version control, CI/CD, observable failure modes). The pitch is that integrations are part of your product and should be built and operated like the rest of your product, with infrastructure underneath that handles the plumbing.

These three categories are not interchangeable. A team that picks Embedded iPaaS because it is the only tool they have evaluated will end up with a different product surface, a different engineering workflow, and a different scaling curve than a team that picks Unified APIs or Integration Infrastructure. The right choice depends on what your product is actually doing with the integration, who is responsible for configuring it, and how deep you need to go into each customer's specific environment.

Unified APIs: Great for Category Reads, Limited for Category Writes

Unified APIs solve a very specific shape of problem: when you need to read normalized data from a class of systems that share a roughly common data model. The canonical example is HRIS. Workday, BambooHR, Rippling, and Gusto all model employees, departments, compensation, and time off in similar (not identical) ways. A Unified API can map all of them to a shared schema, and you write your product against that schema. Same for ATS (Greenhouse, Lever, Ashby), accounting (QuickBooks, Xero, NetSuite), and increasingly for CRM and ticketing categories.

When the use case is "read employee records to populate our SaaS app," a Unified API is genuinely good. You write one integration. Your customer connects whatever system they happen to use. You get reasonably normalized data back. The Unified API vendor handles the per-system auth, the per-system rate limits, and the per-system polling. For category-wide read access into systems that have predictable data models, this category earns its place.

Where Unified APIs run into trouble is everything beyond that core use case.

The first issue is depth. A Unified API by definition exposes the lowest common denominator across the systems it covers. If Workday has a custom field that BambooHR does not, the Unified API has to either drop it or expose it through a generic "custom_fields" pass-through. Your product has to handle that asymmetry one way or another, and you end up writing per-system logic anyway, which defeats some of the point. For systems where the value is in vendor-specific features (NetSuite's custom segments, Salesforce's Apex-driven workflows, HubSpot's custom objects), the unified abstraction either hides what you need or pushes you back into vendor-specific code.

The second issue is writes. Reads are mostly safe to normalize because the worst case is you get less data than you wanted. Writes are unsafe to normalize because the worst case is you write the wrong data into the customer's system of record. Most Unified APIs are read-heavy and write-light for exactly this reason. The ones that do offer writes typically support a narrow set of operations against a narrow set of fields, and they punt on the trickier write paths (bulk writes, idempotent retries, conditional updates against custom objects). For a vertical AI product or a usage-based billing platform that needs to write deeply into the customer's system, this is a real ceiling.

The third issue is per-tenant customization. Unified APIs assume that your product wants the same data shape from every customer. They do not give you a layer where each customer can map their custom fields to your product's schema, configure which records to sync, or override the default mapping for their environment. If your customer base is enterprise and customizes their system of record heavily (which is the case for almost every Salesforce, HubSpot, NetSuite, and Dynamics customer over a certain size), you end up bolting per-tenant configuration on top of the Unified API, which adds complexity without the platform's help.

The fourth issue is performance. Most Unified APIs are pass-through layers that proxy your request to the underlying vendor in real time. That adds a network hop and the same latency stack you would have hitting the API directly, often with less control over caching and aggregation. If your product needs sub-second response times against data that should already be in your system, a pass-through architecture is the wrong shape. There is more on the latency dynamic in How AI Agents Break Every Integration Pattern That Worked for Traditional SaaS, which gets into why request-time fan-out collapses for products that need agent-grade responsiveness.

The bottom line on Unified APIs: ideal for category-wide reads of normalized data in HRIS, ATS, payroll, and similar; usable but constrained for accounting and CRM categories; not the right tool for customer-facing integrations into deeply customized systems of record where you need writes, custom fields, and per-tenant configuration.

Embedded iPaaS: Great for End-User Workflow Configuration, Heavy on the Runtime

Embedded iPaaS sits in a different place architecturally. Instead of giving you a normalized API to a category, it gives you a workflow runtime and a configuration surface, often with a UI you embed in your product. The user (your customer or someone on your team) drags and drops triggers and actions to define what should happen when a record changes in their system, and the iPaaS runtime executes those workflows.

The category has real strengths. For long-tail integrations where each customer wants something slightly different (this CRM record should trigger that Slack notification, that email should create a record in this CRM), Embedded iPaaS lets you ship a configuration surface to customers without building the workflow engine yourself. The visual builder lowers the bar for non-engineers to set up integrations. The trigger-action model is intuitive for the kinds of automation use cases that initially drove the iPaaS category.

The cost of that flexibility is meaningful, and most teams underestimate it.

The first cost is depth. Embedded iPaaS workflows tend to be optimized for trigger-driven automations against a moderate volume of records. They are less well-suited to the patterns most customer-facing integrations actually need: continuous bi-directional sync of large volumes of records, real-time reads against custom objects, bulk writes that have to respect API limits, and aggregation across multiple objects. The platforms can do some of this, but it tends to be the part of the product the workflow builder was not designed for, and the configuration grows complex fast.

The second cost is opacity. The runtime is the iPaaS vendor's, and your visibility into what is happening (and why something failed) is whatever the platform chooses to expose. When a customer reports that their integration is broken, the debugging path goes through the iPaaS dashboard, not through your own logs. That is workable for simple flows. It becomes painful when you are operating thousands of customer integrations and need to triage failures at scale.

The third cost is the configuration surface itself. Embedded iPaaS often pushes the configuration burden onto your customer. The customer is supposed to wire up the integration, map their fields to your product's schema, and define their automation rules. In practice, most customers do not want to do this work. They want the integration to "just work," with sensible defaults and minimal touch. When the configuration UI is the integration, your CS team ends up doing the configuration on behalf of customers, which scales poorly. Teams that have moved off this model often describe the relief of not having to operate a customer-facing config UI for every new integration. There is a longer take on this dynamic in Why migrating from embedded iPaaS to Native Product Integrations Reduces Engineering Overhead.

The fourth cost is engineering ergonomics. Embedded iPaaS workflows are typically defined in a UI rather than in code. That makes them hard to version control, hard to review in a pull request, and hard to test in CI. For engineering teams that operate the rest of their product through git and CI/CD, this is a meaningful step backward. You end up either treating the iPaaS as a separate operational surface (with its own deploy process, its own change management, and its own rollback story) or pushing back into code via custom components, at which point you have lost most of the appeal of the visual builder.

The fifth cost is pricing. Embedded iPaaS often charges per workflow execution, per active user, or per integration enabled, with pricing that scales steeply as you grow. That can be fine for low-volume automation use cases. It tends to bite hard when integrations become a primary product surface and your usage volume is high.

The bottom line on Embedded iPaaS: useful for trigger-driven automations and customer-configurable workflow flexibility in non-core integrations; less useful when the integration is the product, when depth and per-tenant defaults matter, or when engineering wants to own the integration as code with the same rigor as the rest of the codebase.

Integration Infrastructure: Built for Integrations as a Product Surface

Integration Infrastructure was built for the case the other two categories handle awkwardly: when integrations are part of your product, when they need to be deep, when they need to be per-tenant configurable without making the customer do the configuration, and when your engineering team wants to own them as code. That is the gap Ampersand was created to fill.

The design center is integration-as-code. Engineers describe what they want their integration to do in a declarative YAML file. That file lives in their git repo, ships through their CI/CD, and is reviewed in pull requests like any other code. The runtime (Ampersand) reads the declaration and handles execution: managed authentication for every customer who connects their system, scheduled reads that pull data into a queryable layer, on-demand reads and writes through API endpoints your product can call, bulk write optimization that respects API limits, and dashboards that surface per-customer integration health.

The categories of capability Integration Infrastructure provides that the other two do not match are roughly:

• Bi-directional reads and writes at depth. Read from any standard or custom object, write back with idempotency and bulk optimization, and respect the customer's permission model for both directions. This is the dimension where Unified APIs hit their write ceiling and Embedded iPaaS configurations get complex.

• Custom objects and dynamic field mapping. Discover the customer's actual schema, including custom objects they have added to their CRM or custom records they have built in their ERP, and let your product map those into your application's data model. This is the layer that lets your product feel native to each customer's specific configuration. It is covered in more depth in Field Mapping Is How AI Agents Learn Enterprise Reality.

• Multi-tenant managed authentication. OAuth flows for every supported system, automatic token refresh, revocation handling, and per-tenant credential isolation. Auth is its own category of work that grows quietly until it owns a meaningful share of an integration team's time. There is a useful framing in Auth and Token Management Isn't an Integration for teams who have not yet felt this fully.

• Scheduled reads, backfills, and on-demand reads. Pull data on a schedule, do a one-time backfill on connect, or read on demand when your product needs fresh data. The combination matters: pure live reads stack latency, pure scheduled reads get stale, and most products need both modes available depending on the use case.

• Per-tenant configuration without customer-facing UI overhead. Define defaults at the platform level, override per-tenant where needed, and let your team or your customer configure those overrides through whatever UI fits your product. The configuration is not an iPaaS surface; it is a data layer your product reads from.

• Engineering-grade observability. Per-tenant logs, error states, retry visibility, alerting on threshold breaches, and quota management. The runtime is observable in the same shape as the rest of your infrastructure.

The pattern that earns Integration Infrastructure its category is that it stays out of the customer's way. The customer connects their system through whatever connection UI you build into your product. Your product calls Ampersand to read or write. Ampersand handles the underlying complexity. The customer never sees a workflow builder or a configuration UI from the platform. The integration feels like a feature of your product because, in practice, it is. There is more on this stance in What is Integration Infrastructure? for teams who want the architectural framing in full.

Side-by-Side Comparison

The table below compares the three categories across the dimensions that decide which one fits your product.

The table is not meant to dunk on the other two categories. It is meant to make explicit what each one is good at and where each one stops being a good fit. The mistake teams make is using one category to solve a problem that belongs to another.

When to Pick Each Category

The decision is usually clearer than it looks once you have a precise read on what your product is doing.

Pick Unified APIs when you need to read normalized data from a category of systems that share a common data model, where read depth is sufficient, write needs are minimal, and per-tenant customization is not a hard requirement. HRIS, ATS, and payroll are the canonical fits. A workforce planning product that needs to read employee data from whatever HRIS the customer happens to use is the textbook case.

Pick Embedded iPaaS when the integration is genuinely a long-tail automation surface, when end users (rather than your engineering team) are expected to configure the workflows, and when the trigger-action model fits the use case. Notification routing, basic data sync between auxiliary systems, or "when X happens in CRM, do Y in our app" automations that customers want to wire up themselves are good fits.

Pick Integration Infrastructure when the integration is part of your product, when it needs to operate at depth against customer-specific configurations, when bi-directional writes matter, when permissions need to be enforced per user, when you support CRMs and ERPs that vary heavily per tenant, and when your engineering team wants to own the integration as code with the same workflow as the rest of your product. Vertical AI products, customer-facing CRM integrations, usage-based billing platforms that write into NetSuite, and revenue ops tools that operate inside Salesforce are all in this zone. There is a useful piece on the multi-tenant CRM case specifically in Building Multi-Tenant CRM Integrations at Scale: Why Traditional Platforms Fall Short.

The composition pattern matters too. These categories are not always either/or. A SaaS product might use a Unified API for HRIS reads, Integration Infrastructure for its core CRM and ERP integrations, and avoid Embedded iPaaS entirely. Another might use Embedded iPaaS for a marketing automation surface and Integration Infrastructure for the deep customer-data plane. The decision is made integration by integration, not company-wide.

Where Each Category Quietly Pushes Work Back to You

It is worth being honest about the work each category leaves on your team's plate, because the marketing language tends to obscure it.

Unified APIs leave you with the work of mapping the unified schema into your product's actual data model, the work of handling the cases where the unified schema does not cover what you need, the work of building per-tenant configuration on top, and the work of doing your own writes deeply when the platform's write surface is too narrow. For category-wide read use cases, this is manageable. For deeper integrations, it is enough work that the platform stops feeling like a meaningful abstraction.

Embedded iPaaS leaves you with the work of operating a configuration surface (whether you embed the vendor's UI or wrap it in your own), the work of supporting customers who do not want to configure their own integrations, the work of debugging through the vendor's dashboard, and the cost curve as your usage grows. The runtime savings can be real, but the operational and pricing work compounds.

Integration Infrastructure leaves you with the work of writing the integration declaration in YAML, deciding what your data model looks like, and exposing the integration to customers through your own UI. That work is real. It is also the right work to own if your integration is part of your product, because it is the work of building your product.

The honest framing is that there is no platform that takes all the work away. The question is which work the platform takes off your plate, which work it leaves you, and whether what is left is the work your engineering team should be doing.

The Ampersand Pitch, Plainly

If you have read this far, the place we sit in the comparison is clear. Ampersand is the Integration Infrastructure category. We are the layer underneath your product that handles managed auth, dynamic field mapping, custom object discovery, scheduled reads, on-demand reads and writes, bulk write optimization, version-controlled YAML configuration, and per-tenant overrides without making your customers configure their own integrations.

We support NetSuite, SAP, Sage, Salesforce, HubSpot, Marketo, Microsoft Dynamics 365, Zendesk, Gong, and hundreds more systems through a connector library you can extend. We are GDPR compliant and ISO certified. The teams that use us tend to be vertical SaaS and AI product builders who decided early that they did not want to operate an integration platform internally and did not want a workflow builder shoved into their product. Hatch's CTO John Pena described moving to Ampersand as going from "months of maintenance headaches to just not thinking about it." 11x's engineering team described cutting their AI phone agent's response time from 60 seconds to 5 by moving off synchronous integration patterns onto Ampersand's data layer.

For teams who want to go deeper on the architecture, the Ampersand documentation walks through the YAML configuration model, the how it works overview lays out the runtime, and the main Ampersand site has the broader product story. The Best Tools for CRM Integration (2026) post is a useful starting place for teams comparing options in the CRM-integration slice of this space specifically.

FAQ

Are Unified APIs and Integration Infrastructure competitors?

For some use cases, yes. For most, no. Unified APIs win on category-wide reads against systems with normalized data models. Integration Infrastructure wins on deep, per-tenant, bi-directional integrations against customer-specific configurations. Many products end up using both: a Unified API for the categories where it fits cleanly (often HRIS or ATS), Integration Infrastructure for the CRM and ERP layer where depth and customization matter.

Why not just build my own integration platform?

You can, and many teams do, especially in the first twelve months of building integrations. The trajectory is consistent: it works for the first one or two systems, gets harder as customers customize their environments, and eventually becomes a dedicated team within your engineering org maintaining what is effectively a small integration platform. We wrote about this dynamic in The Integration Debt Trap: Why Building Integrations In-House Breaks Down at Scale. Most teams who go this route eventually evaluate the build-vs-buy question more rigorously and decide they would rather have engineers building product than maintaining auth refresh logic.

Doesn't Embedded iPaaS work fine if I'm careful about which workflows I expose?

For limited workflow surfaces, sometimes yes. The cases where it stops working are when your product needs deep, continuous bi-directional sync against customer-specific schemas, when the configuration burden ends up on your CS team rather than on customers, when the runtime opacity makes large-scale debugging painful, or when the per-execution pricing model collides with high-volume use cases. Teams that find themselves customizing around the platform's defaults heavily are usually in that zone.

Can I use Integration Infrastructure for HRIS too, or do I need a Unified API?

You can use Integration Infrastructure for HRIS and many teams do, especially when they need writes, custom fields, or deeper integration than a category-wide API supports. The choice is less about which is "right" and more about which fits your specific use case in that category. For shallow reads of standard fields, a Unified API is faster to ship. For deeper or write-heavy integrations, Integration Infrastructure gives you more leverage.

How do customer-facing UIs work without an Embedded iPaaS configuration surface?

You build your own connection flow (usually a simple OAuth handshake) and a configuration UI that fits your product. The Integration Infrastructure layer powers what happens after the customer connects: it discovers their schema, lets you map fields, runs the syncs, and exposes errors to your product. Your customer sees your UI, not a platform's UI. This is the difference between an integration that feels like a feature of your product and one that feels like a third-party panel you have embedded.

What about pricing across the three categories?

Pricing models differ in ways that matter for total cost. Unified APIs typically charge per connection or per call, with category-specific tiers. Embedded iPaaS often charges per workflow execution, per active connection, or per integration enabled, which can scale steeply with usage. Integration Infrastructure pricing models vary, but the better ones decouple price from per-execution costs and let you scale usage without punitive scaling. There is a more thorough framing of why this matters in Why usage-based integration pricing beats per-connector models for SaaS teams scaling integrations.

Conclusion

Unified APIs, Embedded iPaaS, and Integration Infrastructure are three different answers to three different shapes of integration problem. Unified APIs are the right answer for category-wide reads against normalized data. Embedded iPaaS is the right answer for end-user configurable workflow automation in non-core integration surfaces. Integration Infrastructure is the right answer when integrations are part of your product and need to operate at depth against customer-specific configurations.

Picking the right category is more important than picking the best vendor inside the wrong category. Teams that get this decision right ship faster, scale further, and avoid the slow accumulation of integration debt that comes from forcing one architecture to do work it was not built for. Teams that get it wrong end up either bolting custom logic on top of a platform that was never going to fit, or migrating off the wrong category eighteen months in at significant cost.

If your product is in the zone where Integration Infrastructure is the right call (vertical SaaS, vertical AI, customer-facing CRM and ERP integrations, anything where the integration is the product), Ampersand is the layer to look at. The main site has the full product story, and the docs are a fast way to see whether the model fits how your team works.