An embedded integration platform is infrastructure a SaaS company builds its customer-facing integrations on, so its own customers can connect Salesforce, HubSpot or other tools from inside the product. The category is also called embedded iPaaS. IBM defines it as "a cloud-based integration solution that enables software providers to embed integration capabilities directly into their applications" (IBM). The platform takes on authorization, per-customer configuration, deployment and monitoring. Your team still decides who writes each customer's logic and who fixes it when a customer's setup changes.
That second part is the real decision for a SaaS company. Picking a platform is the easy half. The harder half is choosing an operating model, because your fifth enterprise customer will want a custom object your first four never had. Appnigma offers both halves. Its integration infra says "Deploy integrations, faster" and lets engineers "tailor mappings and workflows to each customer," while its done for you service says "Build your product. We'll build the integrations." If your team is comparing vendors in the category directly, our embedded iPaaS vs Appnigma comparison covers that side by side.
Updated October 2026. The earlier version of this guide used the term "primary embedded integration," which isn't a term the industry or search uses, and it cited no sources. This version uses the standard category names, adds what a connector costs a customer's Salesforce org in API calls, and explains when an embedded connector can or can't become a listed marketplace app, checked against Salesforce and HubSpot developer docs.
How embedded iPaaS differs from iPaaS, unified APIs and in-house builds
Embedded iPaaS, traditional iPaaS and unified APIs get mixed up in vendor pages with in-house builds, done-for-you delivery and native marketplace apps. Several vendors sell more than one of these models. The table sorts them by who uses the integration and who owns the work after launch.
| Model | Built for | Who configures each customer | Who maintains it after launch |
|---|---|---|---|
| Traditional iPaaS (such as MuleSoft or Boomi) | A company's own IT team connecting internal systems | Your IT team, once | Your IT team |
| Embedded iPaaS | A SaaS product offering integrations to its customers | Your customers, through a setup screen your team defines | Your engineers, on the vendor's runtime |
| Unified API | Engineers who want one API across many apps in a category | Mostly fixed, with field-level extensions in some products | The vendor maintains the common model, you maintain your use of it |
| In-house build | Teams with integration engineers and few target systems | Your engineers | Your engineers, including auth and infrastructure |
| Done-for-you delivery | Teams that want integrations shipped without staffing them | The delivery team, with your approval | The delivery team, as an ongoing engagement |
| Native marketplace app | Buyers who want to install your app inside Salesforce or HubSpot | The customer admin, inside their own CRM | Whoever builds the app, through package or app updates |
A unified API is a single API that stands in for many apps of one type, such as one CRM endpoint that reads contacts from several CRMs through a shared data model. It suits a product that needs the same fields from 30 HRIS or CRM systems. It suits less well when one customer needs a custom Salesforce object that the shared model doesn't include.
Embedded does not mean a fixed data model. Several embedded vendors describe code-first integrations and customer-specific configuration in their own documentation. So the useful test is to take one real customer exception and build it during the trial, rather than trust a category label. Our comparison of native integration and iPaaS tools like MuleSoft, Boomi and Zapier covers the internal IT side of that split.
What the platform handles and what your team still owns
An embedded integration platform removes the plumbing that every integration repeats. That usually means OAuth app registration and token storage, a setup screen your customer clicks through, a runtime that executes each customer's integration, and logs per customer connection. Appnigma's integration infra page lists the same stages for its own product, from "app registration and authorization" through testing in sandboxes to the ability to "monitor each customer's connections."
What stays with you is the part customers notice. Somebody writes the default mapping between your objects and Salesforce's. Somebody decides what happens when Customer B maps shipping city where everyone else uses billing city. And when a customer's admin renames a field on a Friday, somebody reads the error, changes the mapping, tests it and releases the fix. Logs show what broke. They don't fix it.
That gap is why the operating model matters more than the feature list. A team with two integration engineers can run an embedded platform well. A team whose engineers are all on the core product often ends up with a well-monitored backlog of integration bugs. In that case a delivery model fits better. Appnigma's done for you page promises "ongoing maintenance from a named integration engineer," with backend changes and testing included.
What one connector costs a customer's Salesforce org
Every API call your integration makes counts against the customer's own Salesforce allocation, whichever platform makes it. Salesforce enforces the limit "against the aggregate of all API calls made to the org in a 24-hour period" (API Request Limits and Allocations). Enterprise Edition gets "100,000 + (number of licenses x calls per license type)," and each Salesforce license adds 1,000 calls. Packaging doesn't change this. The same page says "API calls made from installed managed packages, count against your org limit."
Here is the arithmetic for a mid-size customer, worked from those documented numbers. An Enterprise Edition org with 15 Salesforce licenses gets 115,000 calls per 24 hours. A connector that polls four objects every five minutes makes 4 x 288 = 1,152 calls a day, about 1% of that allocation. A nightly re-sync of 200,000 records written one record per call would make 200,000 calls and run past the whole allocation. The same re-sync through sObject Collections, which accepts up to 200 records per request (sObject Collections upsert), takes 1,000 calls.
The other apps in that org share the same 115,000. So the cost that matters in an evaluation is what each sync pattern does to the customer's allocation, not the platform's own pricing unit. Event-driven sync cuts polling. Salesforce Change Data Capture "publishes change events, which represent changes to Salesforce records," and HubSpot webhooks send "a POST request to your specified endpoint whenever subscribed events occur" (HubSpot webhooks). Our guide to platform events and Change Data Capture covers which one to pick.
Can an embedded connector become a listed marketplace app?
It can on both platforms, but the listing belongs to your app and has its own review. An embedded connector is an integration your product runs. A marketplace app is a listing customers find in Salesforce AgentExchange (the marketplace Salesforce docs formerly called AppExchange) or the HubSpot App Marketplace. Enterprise buyers often ask for the second.
On Salesforce, a package is not required to list, but review is. The security review guidelines name "Salesforce Platform API solutions" alongside managed packages and say they "must pass our security review" to be distributed on AgentExchange. For new OAuth apps, Salesforce now says "Starting in the Spring '26 release, you can't create new Connected Apps. Use ECAs instead" (External Client Apps for partners). The same page notes that "Salesforce invalidates the idle refresh token after 30 days," so a customer connection that sits unused for a month needs a reconnect path. Read more about what an External Client App is.
On HubSpot, the listing is tied to one app identity. The listing requirements ask for "OAuth as its sole authorization method" and "at least three active, unique installs," and API requests must use "the public HubSpot app ID (and OAuth client ID) associated with your app listing." HubSpot's marketplace restrictions also bar "white-label integration infrastructure" listings, meaning apps designed to sit invisibly inside another party's product. So if you plan to list, check that the platform lets you register and run your own HubSpot app rather than a shared one. Our guide to HubSpot integration platform patterns covers how embedded-platform apps get listed. Unlisted apps on the current platform are "capped at 25 installs until they are listed" (HubSpot changelog), and certification needs "at least 60 active, unique installs" (certification requirements).
Appnigma's marketplace apps work covers this step as a separate project. Its page offers "a native app, marketplace listing preparation, and review support" and adds that a listing "is not a promise of inbound leads."
How SaaS teams choose between building, embedding and handing off
Start from the customer requests you already have, not the vendor list. Count how many distinct systems customers ask for, and how many of those customers need objects or fields beyond your default mapping. Five systems with standard objects is a different problem from two systems where every enterprise customer has custom objects.
An embedded integration platform is usually the better choice when you need many connectors, your engineers want to own the code, and customers configure most differences themselves in a setup screen. A unified API fits when the fields you need are common across a category. Building integrations in house makes sense with one or two deep integrations and engineers who already know those APIs well.
Handing the work off fits when the integration backlog competes with the product roadmap, or when each customer's requirements differ enough that someone has to scope them one by one. Appnigma's done for you service supports "each customer's objects, field mappings, and workflows," with maintenance included. For teams that want to keep the code, the integration infra gives engineers the same foundation. And when buyers ask for a listing in Salesforce or HubSpot, the marketplace apps project is a separate step on top of either. Our build vs buy guide for bidirectional sync works through the cost side of that choice.
Whichever model you pick, run one real customer exception through it before signing. Add a custom object, change one mapping for one customer, then push an update to the base integration and check that the exception survives.
Mistakes SaaS teams make with embedded integrations
- Testing the trial against a fresh demo org with no custom fields, then finding the first enterprise customer has dozens of them.
- Treating per-customer logs as maintenance. Someone still has to be on the hook for the fix.
- Running a full re-sync as single-record calls and using up a customer's daily API allocation.
- Assuming a connector on a vendor's shared OAuth app can be listed on the HubSpot App Marketplace under your name.
- Leaving out a reconnect flow, so a Salesforce connection whose refresh token went idle for 30 days fails quietly.
- Planning a HubSpot launch without counting the installs needed to list, then hitting the 25-install cap for unlisted apps.
Frequently Asked Questions
What is an embedded integration platform?
It is infrastructure a SaaS company uses to offer integrations inside its own product, handling auth, per-customer setup, runtime and monitoring. The category is also called embedded iPaaS.
What is the difference between embedded iPaaS and a unified API?
An embedded iPaaS runs separate integrations per app that you or your customers configure. A unified API gives you one standard API across many apps of the same type, which is faster to start but limited to the shared fields.
Do API calls from an embedded integration count against the customer's Salesforce limits?
Yes. Salesforce counts every API call to the org against its 24-hour allocation, including calls from installed managed packages, so batch writes and event-driven sync matter.
Can an app built on an embedded integration platform be listed on the HubSpot App Marketplace?
Yes, if it runs under your own public HubSpot app with OAuth and has at least three active installs. HubSpot doesn't list white-label integration infrastructure meant to sit invisibly inside another product.
Can Appnigma build our customer integrations instead of us using an embedded platform?
Yes. Appnigma's done for you service builds and maintains customer integrations with a named integration engineer. Teams that want to build themselves can use its integration infra instead.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- Embedded iPaaS vs Appnigma for customer integrations
- Salesforce integration tools compared
- Connected apps vs External Client Apps
- The HubSpot App Marketplace guide
- HubSpot API rate limits for public apps
Sources
- What is embedded iPaaS?, IBM
- API Request Limits and Allocations, Salesforce Developer Limits and Allocations Quick Reference
- Upsert Records Using sObject Collections, REST API Developer Guide
- Change Data Capture Developer Guide
- Security Review Guidelines and External Client Apps, ISVforce Guide
- App Marketplace listing requirements and Marketplace restrictions, HubSpot Developers
- Certification requirements, HubSpot Developers
- New marketplace distribution app install limits, HubSpot Developer Changelog
- Configure webhooks, HubSpot Developers
