What Is an Embedded iPaaS? (And Why AI Is Changing It)

An embedded iPaaS is integration infrastructure that lives inside your product, so your customers connect their own systems without you building a bespoke integration for each one. Instead of shipping a Salesforce connector, then a HubSpot connector, then the twelve others your enterprise deals keep asking for, you ship one connection experience and let each customer authenticate whatever they already run.

The distinction that matters is who the integration is for. A classic iPaaS (think of the automation tools an ops team wires up internally) connects systems your company uses. An embedded iPaaS connects systems your customers use, from inside the product you sell them. That single change in audience drives every architectural requirement below.

Why per-tenant is the whole problem

Internal integrations authenticate once. You store one set of credentials, you point at one instance, and if the schema changes you fix it once. Customer-facing integrations invert all three assumptions. Every tenant brings their own account, their own OAuth grant, their own custom fields, their own object naming, and their own admin who may revoke access on a Friday afternoon.

That means the state you have to manage is not one connection but one connection per customer per system, each with an independent token lifecycle. The work that quietly eats engineering time is not writing the first API call. It is refresh-token rotation, per-tenant rate limiting, partial failures that must not leak across tenants, replaying webhooks after downtime, and mapping one customer's custom field to the canonical field your product expects.

• •Auth: per-tenant OAuth grants, token storage, refresh, and revocation handling
• •Isolation: one tenant's failure, rate limit, or bad data must never touch another's
• •Schema drift: custom fields and objects differ per customer and change without notice
• •Observability: when a sync breaks you need to know which customer, which object, which call
• •Upkeep: vendors deprecate endpoints on their schedule, not yours

The build-versus-buy maths people get wrong

Teams usually estimate the first integration and multiply. That underestimates badly, because the cost curve is not linear in the number of connectors. It is driven by the number of live tenant connections and by how many different vendor APIs you are on the hook to maintain.

A useful way to sanity-check the estimate: the first connector is a sprint, the fifth is a backlog, and the twentieth is a team. Maintenance dominates. Once integrations are in customer hands, a broken connector is a support ticket and a churn risk, not a tidy-up task, and it lands with no warning when a vendor ships a change.

The question is not whether you can build one integration. It is whether integrations should be a permanent line item on your roadmap.

What AI agents changed

When a human clicks a button, the integration only needs to be correct. When an AI agent calls it autonomously, the integration also needs to be governed. The agent may attempt actions nobody explicitly reviewed, so the boundary of what it can do has to be enforced by infrastructure rather than by user interface.

In practice that means three things beyond a normal integration layer. Access has to be scoped per tenant, so an agent acting for one customer cannot read another's data. Every call has to be audited, because you will be asked what the agent did and on whose behalf. And tool descriptions have to be accurate enough for a model to choose correctly, which makes schema quality a runtime concern rather than documentation.

How to evaluate an option

Whether you build or buy, judge the approach against the failure modes that actually occur in production rather than the demo:

• •What happens when one customer revokes OAuth access mid-sync?
• •How are a customer's custom fields mapped without shipping code for that customer?
• •Who fixes it when the vendor deprecates an endpoint, and how fast?
• •Can you prove, per tenant, what an agent read and wrote?
• •What does supporting the twentieth connector cost compared with the first?

The answers tend to separate options faster than a feature grid does, because they are the questions that turn into support load six months after launch.