What 650 Connectors and 10B Weekly Records Mean for Your SaaS Roadmap

Your first production integration probably went fine. Your fifteenth is where things get interesting. Connector maintenance, schema drift, tenant isolation, partial sync failures at 2am... these are the problems that only show up at volume, and they tend to show up all at once. If your roadmap includes scaling embedded iPaaS across a growing customer base, the architecture questions are worth asking now, not after the third outage.

TLDR:

• Embedded iPaaS lives inside your product so customers connect their own tools without leaving your app.
• Building integrations in-house starts cheap but compounds fast — one connector becomes three engineers on rotating on-call.
• Your integration costs should stay under 10% of MRR from integrated customers; volume-based billing makes that ratio hard to track.
• MCP changes what "integration" means on your roadmap: connectors now need real-time agent-driven reads and writes, beyond batch jobs alone.
• Hotglue runs 38,000 active tenants processing 10 billion records weekly, with tenant-based pricing where one customer across multiple connectors counts as one tenant.

What Embedded iPaaS Actually Is (and What It Isn't)

An embedded iPaaS is a multi-tenant integration layer that lives inside your product. Your customers connect their own tools, like Salesforce, QuickBooks, or Shopify, without ever leaving your app. Authentication, data orchestration, and sync scheduling all happen underneath, invisible to the end user.

Traditional iPaaS tools like Workato or MuleSoft were built for IT teams wiring together internal systems. As Pandium explains, embedded iPaaS is purpose-built for product and engineering teams who need to ship scalable, reusable customer integrations as part of their roadmap. If you're new to the concept, embedded iPaaS explained is a good place to start. Different buyers, different problems.

Unified APIs are a related but distinct category. They abstract connector differences behind a common schema, which is convenient, but can hide vertical complexity you'll eventually need to deal with. Embedded iPaaS gives you the full connector, not just a normalized slice of it.

Embedded iPaaS vs. Building Integrations In-House

The most common objection we hear is some version of "our engineers already handle this." And sometimes that's true — for one or two integrations, a tight scope, a stable API. But the calculus changes fast. (Spoiler: the engineers who said it's fine are now the ones on PagerDuty at 2am.)

Building a connector is the easy part. Maintaining it is where the hidden cost lives. Third-party APIs deprecate endpoints, change auth flows, and shift field names without notice. Each change requires triage, a fix, a test cycle, and a deploy for every customer running that connector. One variation, say a customer using Shopify with Loop Subscriptions layered on top, can effectively mean rebuilding the connector from scratch.

The math compounds across your catalog:

• Every new connector added in-house is a permanent maintenance commitment, not a one-time cost you can budget and forget.
• Schema drift from upstream API changes can break syncs silently, meaning customers lose data before anyone notices.
• One engineer's "quick integration" tends to become three engineers' rotating on-call burden a year later, a pattern covered in depth in the guide on building user-facing SaaS integrations yourself.

"Engineers underestimate the ongoing maintenance burden. API endpoint changes, schema variations, connector rebuilds — these can consume months of engineering time that was never budgeted for."

Building in-house has real advantages if you need deeply custom logic, have unusual data models, or are integrating with a system no vendor supports. An embedded iPaaS works best when you're repeating the same pattern across many connectors and many customers — and that's exactly where absorbing the maintenance cost internally stops making sense.

Who Actually Needs Embedded iPaaS (and When)

Most B2B SaaS companies don't reach for an embedded iPaaS until a customer forces the issue. One enterprise prospect says "we need a NetSuite sync before we can sign," and suddenly integrations are on the roadmap whether engineering planned for it or not.

The trigger matters less than recognizing the pattern when it repeats.

Early-stage SaaS (under $5M ARR)

One integration, built in-house, is usually fine. You know the customer, you control the scope, and the maintenance burden is manageable for one engineer. The embedded iPaaS conversation starts when request three or four lands and you realize you're building an integrations team instead of a product.

Growth-stage SaaS ($5M–$50M ARR)

Your catalog is expanding, customer segments are diverging, and engineering is getting pulled between integration tickets and core product work. Saying no to an integration is now a real sales and retention risk. This is where the build-vs-buy calculus tips.

Who feels the pain first — and who owns the fix

Almost never engineering. The pain surfaces through customer success, partnerships, or sales long before it reaches a sprint. In practice, the Head of Partnerships or CPO is typically the one who feels the revenue impact first — a deal stalled on a missing connector, a renewal at risk because a sync broke — and ends up owning the decision to build or buy. Engineering often comes in as a skeptic, then becomes the champion once they realize they're gaining more control, not less — which speaks directly to the stigma of embedded iPaaS that teams carry into the evaluation.

Key Features That Define a Production-Ready Embedded iPaaS

Not every embedded iPaaS holds up once you have real tenants running real syncs. Here's what separates production-ready from "works in the demo":

• Connector depth, alongside breadth. A connector that covers 80% of a system's objects fails the 20% your enterprise customer needs. Look for on-premise support too: QuickBooks Desktop and Sage 300 CRE break most vendors.
• True multi-tenant isolation. One tenant's bad sync should never affect another's job queue or data state.
• Transformation flexibility. Python-based mapping scripts beat drag-and-drop mappers the moment your data model diverges from the connector's default output.
• Flexible scheduling. Cron-based, per-connector frequency — not a global sync cadence applied to everything.
• Guaranteed sync behavior. Partial failures should fail loudly, not silently succeed and corrupt downstream records.
• Compliance out of the box. SOC 2 Type II and GDPR aren't nice-to-haves once you're selling to mid-market or enterprise buyers.
• Observability. Job health monitoring and actionable failure alerts matter more than a status page. If your CS team finds out about a broken sync from the customer, the tooling failed before the integration did.

The Embedded iPaaS Market in 2026

The iPaaS market is projected to grow from $15.9B in 2026 to $55.5B by 2033, a 19.6% CAGR that reflects how deeply integration has moved from infrastructure concern to product requirement. Companies now rely on over 250 SaaS applications on average, each one a potential sync your customers expect your product to handle natively. That pressure lands on your roadmap.

Connector Breadth vs. Connector Depth: Why Both Matter

Having 650 connectors matters, but only if each one actually works when a customer's enterprise stack gets involved. Breadth tells you which doors exist. Depth tells you whether they open.

Depth means covering the edge cases: on-premise systems, legacy auth flows, and obscure object types that enterprise customers rely on daily. Most embedded iPaaS vendors stop at cloud APIs because on-premise connectors are genuinely hard to build. QuickBooks Desktop runs through a Windows agent, Sage 300 CRE installs directly on the customer's machine and connects to the local database, and Sage 200 connects via a cloud proxy. That kind of coverage closes enterprise deals.

Breadth still matters. A catalog that covers accounting but misses e-commerce, or handles CRM but skips payroll, forces your sales team to say no. The goal is both: enough connectors to cover your ICP's stack, built deeply enough that each one holds up in production.

The failure mode to avoid is treating connector count as a proxy for connector quality — one of several iPaaS evaluation pitfalls for product managers worth reading before you shortlist vendors. Integration debt accumulates there quietly, through connectors that break on API version changes, drop fields silently, or can't handle non-standard configurations. That's a support ticket waiting to happen.

Scalable Integration Architecture Patterns for B2B SaaS

Per-connector scheduling matters more than most teams expect early on. A customer syncing Salesforce needs hourly updates. Their QuickBooks sync can run nightly. A uniform cadence either over-syncs cheap connectors or under-syncs time-sensitive ones. Cron-based scheduling per connector, configurable per deployment, is what production actually requires.

Stateful sync design separates demos from real products. Pulling a full data dump on every job is expensive, slow, and fragile. Incremental sync, backed by snapshots that preserve where each tenant left off, keeps jobs fast and makes retries safe. If a sync fails mid-run, the job should hold state for retry instead of partially committing records and moving on.

The transformation layer deserves its own separation from connector logic. When your data model diverges from a connector's default output, and it will, you need a place to reshape data without touching the connector itself. Python-based mapping scripts handle that cleanly. Drag-and-drop mappers hit a wall the moment a customer has non-standard field names or nested JSON that needs flattening.

Multi-tenancy ties all of this together. Each of your customers runs their own connected accounts, sync schedules, and field mappings. If your integration layer treats them as a shared resource, one tenant's misbehaving job degrades everyone else's experience. At 38,000 tenants processing roughly 10 billion records weekly, the difference between a well-isolated, stateful architecture and a naive one is the difference between a system that scales and one that pages your on-call at 2am.

Embedded iPaaS Pricing Models and How Costs Scale

Pricing structures vary more than most teams realize until they're mid-contract and scaling fast. The four common models break down like this:

Volume-based billing is the one to watch closely. A single customer running a full historical backfill can generate a bill that has nothing to do with the value they're getting, which is worth considering alongside a comparison of hotglue vs. Powered by Fivetran. Tenant-based pricing avoids that problem because the unit of billing maps directly to the unit of business value: one paying customer, one tenant.

Hotglue prices on active tenants within a rolling 30-day window, and a single tenant connecting to multiple connectors still counts as one tenant. At 5,000 tenants, that model scales predictably without surprise invoices from an unusually large sync job.

One rule worth applying early: your integration costs should stay under 10% of the MRR you're generating from integrated customers. If the pricing model makes that ratio hard to calculate, that's a signal.

How MCP and AI Agents Are Changing the Integration Layer

Scheduled ETL and AI agent access solve different problems. A nightly sync from QuickBooks works fine when a human reviews a report each morning. It stops working when an AI agent needs to check an invoice status mid-conversation, or when an LLM-powered workflow needs to write a journal entry in real time based on something that just happened upstream.

Model Context Protocol (MCP) is the new standard that lets AI agents authenticate with and act on external systems through a consistent interface. Instead of hardcoding API calls per system, an agent finds available tools from an MCP endpoint and executes them with the right credentials. The integration layer becomes the secure gateway, not merely the data pipe.

For product teams, this changes what "integration" means on the roadmap. A connector that was previously useful for scheduled data sync now also needs to support real-time, agent-driven reads and writes. That is a different architecture requirement than a batch job that runs at 2am.

Hotglue's Composite MCP server (https://mcp.hotglue.com/mcp) exposes the tools available from whichever connectors a tenant has already linked, namespaced per system. A tenant that connected Notion and QuickBooks gets notion.search and the relevant QuickBooks tools without re-authenticating through each upstream system separately. The auth each tenant completed through the widget or Magic Link carries over directly into the agent context.

How to Assess and Choose an Embedded iPaaS Vendor

When reviewing vendors, the table below covers the criteria that actually separate a reliable embedded iPaaS from one that creates ongoing headaches.

A few of these deserve more than a checkbox. Connector depth is the one that bites teams late. Ask any vendor directly about QuickBooks Desktop, Sage 300, or whatever legacy system your largest prospects actually run. If the answer is vague, that connector will become your support team's problem.

Support model matters more than most vendor comparisons cover. The real question is what happens when a third-party API breaks at 11pm before a customer's month-end close — context that's useful alongside a review of the different iPaaS integration platforms on the market. A ticketing queue and a shared Slack channel with a team that knows your integration stack are very different experiences. Ask for a concrete example of how the vendor handled an upstream API deprecation.

Developer experience is worth a hands-on test, not a demo. Can your engineers fork a connector, run it locally, and push a custom mapping via CLI? For a structured framework, see choosing the best embedded iPaaS solution for your specific needs. If each step requires a support ticket, that friction compounds across your entire catalog build.

What hotglue's Scale Means for Product Teams Building on Embedded iPaaS

38,000 active tenants, 10 billion records processed weekly. That's the current operating state, running on AWS ECS via Fargate with multi-tenant isolation and stateful sync architecture baked in.

For product teams, the practical value here is that the failure modes only visible at volume are already solved. Tenant isolation, partial failure handling, incremental sync, and connector resilience across thousands of simultaneous connections are production-proven.

A few real examples:

• Tipalti syncs payees, bills, and approvals bidirectionally, with data volumes contributing to that 10B weekly record count.
• Airwallex syncs bills, expenses with attachments, GL accounts, vendors, custom fields, and tax rates across a global customer base.
• Linnworks powers their Faire marketplace integration through Hotglue, covering orders, inventory, and fulfillment sync.
• Rillet runs bidirectional Paylocity and Airbase integrations with journal entry automation built on top of the transformation layer.

The 650+ open-source connectors mean your engineers can inspect, fork, or extend anything in the catalog. New connectors typically go from API access to live in one to two weeks, which changes how you scope your roadmap. A connector your sales team needs for a deal next quarter becomes a real commitment.

Tenant-based pricing keeps costs predictable as you grow. One customer connecting to QuickBooks, Shopify, and Salesforce counts as one tenant, not three.

Final Thoughts on Scaling ETL and Embedded Integrations for B2B SaaS

Getting integrations right is less about picking the longest connector list and more about finding a layer your engineers can trust at 3am when something breaks. Connector depth, true multi-tenant isolation, and predictable pricing are the details that matter once you're past the demo stage. See how it all fits together at hotglue.com/demo.

FAQ

Embedded iPaaS vs building integrations in-house: what should a product team actually choose?

Building in-house works for one or two integrations with a stable API and a clear scope. The calculus flips once you have three or more connectors, because each one becomes a permanent maintenance commitment — API endpoint changes, schema drift, and auth deprecations all require triage and redeploy cycles across every customer running that connector. An embedded iPaaS like Hotglue absorbs that ongoing cost, which is where the real savings come from, not the initial build.

What is the best embedded integration platform for B2B SaaS products in 2026?

The right answer depends on your connector requirements, but the criteria that actually separate production-ready from demo-ready are: on-premise connector support (QuickBooks Desktop, Sage 300 CRE), true multi-tenant isolation, Python-based transformation flexibility, and a support model with a dedicated channel instead of a ticket queue. Hotglue covers all of these and runs at 38,000 active tenants processing roughly 10 billion records weekly, so the failure modes that only appear at volume are already solved.

What are MCP servers and why do they matter for SaaS integrations in 2026?

Model Context Protocol (MCP) is a new standard that lets AI agents authenticate with and act on external business systems through a consistent interface, instead of hardcoding API calls per system. For product teams, a connector that previously handled scheduled batch syncs now also needs to support real-time, agent-driven reads and writes: a different architecture requirement than a nightly job. Hotglue's Composite MCP server at https://mcp.hotglue.com/mcp exposes tools from whichever connectors a tenant has already linked, so the auth a tenant completed through the widget or Magic Link carries over directly into the agent context without re-authentication.

How does Hotglue price per-tenant costs as a partner scales, and can integration costs be passed through to end customers?

Hotglue prices on active tenants within a rolling 30-day window, and a single customer connecting to QuickBooks, Shopify, and Salesforce counts as one tenant — not three. The target is to keep integration costs under 10% of the MRR generated from integrated customers. Hotglue supports multiple commercial models for partners, including passing costs through to end customers, referral arrangements, and reseller structures, so you can match the pricing model to how your own product is sold.

How quickly can Hotglue build a new connector for a platform it does not yet support?

Once API access or sandbox credentials are available, Hotglue typically goes from access to a live connector in one to two weeks. That turnaround changes how you scope your roadmap: a connector your sales team needs for a deal next quarter becomes a real, plannable commitment instead of an open-ended engineering ask.