The nine levels of integration climb from manual transfer and file exchange to shared database and point to point links. Above those sit API based, event driven and process integration, with experience and intelligent integration at the top. Each level moves data with less human work and tighter timing than the one before it, and each costs more to build and run. No standard defines nine levels of software integration. This list is Appnigma's nine-level model, built from the integration styles architects already use. The closest formal model is The Open Group's OSIMM, which has seven levels.
Two other nine-level lists share the name. If you came for psychology, Dan Siegel's nine domains of integration come from interpersonal neurobiology, which he introduces on his own site. If you came from systems engineering, Integration Readiness Levels rate how mature the interface between two technologies is on a nine-point scale, described in this IRL research paper. This page covers software integration.
Most guides read the ladder as a score for a company's internal systems. For a SaaS company the useful reading is different. It describes what you ship into each customer's Salesforce org or HubSpot portal, from a CSV export up to a native app that runs inside their CRM and is listed on the marketplace. Every level you climb is something you build once and then run in every customer's account. Appnigma does that work for SaaS teams. The done for you service puts it as "Build your product. We'll build the integrations."
Updated October 2026. Checked against Salesforce's Integration Patterns and Practices guide (Winter '27), the Salesforce API limits and packaging docs, and HubSpot's developer platform docs. The earlier version of this post presented the nine levels as an established framework and gave no sources. It also listed database integration as a Salesforce option and "Streaming APIs" as current. This update says where the levels come from, maps each one to Salesforce's six official patterns, marks PushTopic as legacy and adds what each level costs per customer org.
The nine levels at a glance
Each of the nine levels means something concrete for a SaaS company whose customers run Salesforce or HubSpot. The last column shows who carries the ongoing work, which is what decides whether a level is worth offering.
| Level | How data moves | What it looks like for a SaaS product | Who carries the work |
|---|---|---|---|
| 1. Manual | People copy or re-key records | Customers paste data from your app into their CRM | The customer, every day |
| 2. File based | Scheduled CSV or SFTP files | A CSV export customers load with Data Loader or HubSpot import | The customer's admin |
| 3. Database | Direct reads of another system's tables | Not offered by Salesforce or HubSpot to vendors | Not available |
| 4. Point to point | One custom connection per pair of systems | A script or connector built for one customer | You, once per customer |
| 5. API based | Documented, versioned APIs | Your public API, plus your code calling the customer's CRM API | You and the customer's developers |
| 6. Event driven | Systems publish and subscribe to events | Change Data Capture, platform events or HubSpot webhooks feed your backend | You, with infrastructure to receive events |
| 7. Process | A business flow spans several systems | Your product's steps run inside the customer's lead to cash flow | You, plus the customer's admin |
| 8. Experience | One screen over several systems | Your UI inside the CRM record page as a component or app card | You, as an installed app |
| 9. Intelligent | Systems route and recover with little human input | Automated retries, routing and anomaly alerts per customer connection | You, as an operations practice |
Two levels need a correction against the platforms' own docs. Level 3 isn't available to vendors on either CRM, and level 9 is mostly operations work rather than a separate tier.
Where the nine levels come from
The nine-level list is Appnigma's model, not a standard. A scan of Salesforce's developer documentation and HubSpot's developer docs finds no page that defines integration levels or an integration maturity model. Salesforce's own taxonomy sits in the Pattern Selection Guide, which "Specifies the style of integration: Process, Data, or Virtual" and then splits each style by synchronous or asynchronous timing.
The formal model people usually mean by "integration maturity" is OSIMM, The Open Group Service Integration Maturity Model, also published as ISO/IEC 16680:2012. Its source book says "At the heart of OSIMM are the seven levels of enterprise business and IT service-integration maturity." The levels run from Silo through Integrated, Componentized, Service, Composite Services and Virtualized Services to Dynamically Re-Configurable Services. OSIMM measures how far a whole enterprise has moved toward services. It says nothing about what a software vendor should ship into a customer's account, so it can't settle the SaaS question. The opengroup.org page now returns an error, so the link above points to the archived copy.
Vendor maturity models from iPaaS companies usually have five stages and grade a company's internal connectivity. They are useful for an IT team planning its own stack. They answer a different question from the one a SaaS product leader asks, which is how deep into each customer's CRM the product should go. The level names overlap with the four types of integration, which sort the same work by what gets connected rather than by depth.
How the levels map to Salesforce's six integration patterns
Salesforce's Integration Patterns and Practices guide lists six patterns and rates the tools for each as Best, Good or Suboptimal. The guide is written from the customer org's point of view, so your SaaS product is the "remote system" in every pattern. Our walkthrough of the six Salesforce integration patterns covers each one in more depth.
| Level | Salesforce pattern | Tool the guide rates Best | What that means for you |
|---|---|---|---|
| 2 and 5 | Batch Data Synchronization | Change Data Capture when Salesforce is the master, an ETL tool calling Bulk API when your system is | Bulk loads go through Bulk API, not record by record calls |
| 5 | Remote Call-In | REST API and SOAP API | Every call your backend makes into the org is synchronous |
| 6 | Fire and Forget | Process driven platform events | The org publishes, your service subscribes and acknowledges |
| 7 | Request and Reply | Enhanced External Services called from a flow | Your API needs an OpenAPI definition the customer's flow can call |
| 8 | UI Update Based on Data Changes | Streaming API (see the status note below) | The record page refreshes when your data changes |
| 8 | Data Virtualization | Salesforce Connect | Your data shows in the org without being copied into it |
Two details in that guide change design decisions. The Remote Call-In page says "Remote calls to Salesforce are always synchronous request-reply," so your backend holds a connection open for each call and has to queue its own retries. The Batch page rates record by record call-in as Suboptimal because it "causes considerable on-going traffic between the two systems." Any sync above a few thousand records belongs on Bulk API 2.0, and the guide says "Any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0."
The UI Update pattern still recommends Streaming API with a PushTopic. The newer event comparison page says "PushTopic and generic events are legacy products," and names Change Data Capture and platform events as the replacements. New builds should start there and subscribe through Pub/Sub API. Choosing between the two is covered in Platform Events vs Change Data Capture.
Which levels a SaaS product can ship into a customer's CRM
Level 3 is the first that drops out. Neither platform documents direct database access for a vendor. Salesforce's official routes are its APIs and Data Loader for CSV files. The third is Salesforce Connect, whose external objects "map to data located outside your Salesforce org." HubSpot offers its APIs, CSV import and export, and a Snowflake Data Share on Data Hub Enterprise that the customer queries in their own Snowflake account. A pitch that promises database level sync with a customer's CRM is describing API calls.
Level 4 looks cheap for the first customer and stops scaling at the fifth. Every point to point connection is built against one customer's fields, objects and automation. When you have forty enterprise customers, you run forty slightly different integrations, and a change for one can break another. The fix is either a shared integration with per customer configuration or a packaged app.
Levels 5 and 6 are where most SaaS products sit. Your public API lets customers' developers pull data, and your own code calls their CRM's API to push it. Events cut the polling. HubSpot's webhook docs say that "Instead of repeatedly polling HubSpot's APIs to check for changes, webhooks push event data to your application as soon as it happens." Events don't remove the work, though. Salesforce's Batch page notes that Change Data Capture "requires an integration app for receiving events and performing updates in the external system." That app is yours to build, host and monitor, whether it receives Salesforce events and outbound messages or HubSpot webhooks.
Level 8 needs an installed app. A component on the account record page or a HubSpot app card only exists if you ship something into the customer's account. On Salesforce that is a managed package, "a container for an app that you plan to sell and distribute to Salesforce customers," with Lightning Web Components or a Canvas app inside. On HubSpot it is an app on the current developer platform, since legacy public apps "can no longer be created" as of June 23, 2026, per the legacy apps overview. An API or iPaaS integration has no screen inside the CRM.
What level of integration should a SaaS company offer?
Most SaaS companies end up offering several levels at once, one per customer segment. The five options below are what SaaS teams actually ship to customers on Salesforce or HubSpot, from lightest to deepest.
| What you ship | Ladder level | Who builds it | Who maintains it | When it fits |
|---|---|---|---|---|
| CSV export and import template | 2 | You, once | The customer's admin runs it | Small accounts, one-off migrations |
| Public API and docs | 5 | You, once | Your platform team, the customer's developers build on it | Customers with their own engineers |
| Connector on an iPaaS | 4 to 6 | You or the iPaaS vendor | Shared, the customer configures each flow | Customers who already run that iPaaS |
| Integration you run for each customer | 5 to 7 | You | You, per customer connection | Mid-market and enterprise accounts that want it to just work |
| Native app in the customer's CRM | 6 to 8 | You, as a managed package or HubSpot app | You, through versioned releases | Enterprise accounts that want your data on CRM records, plus marketplace discovery |
The deciding question is who carries the work after launch. A CSV template costs you almost nothing and moves the work to the customer. A native app moves all of it to you, and in return your product shows up where the customer's sales team works. An iPaaS connector sits between the two and depends on the customer already paying for that platform. Our comparison of Salesforce iPaaS and a native app and our guide to what an embedded integration platform handles go deeper on the middle rows.
What each level costs per customer org
Integration cost for a SaaS company grows with customer count, and the build is the smaller part. The larger part is the API budget you spend in each customer's account and the hours spent keeping each connection healthy.
Salesforce gives each org a daily API allocation of 100,000 calls plus 1,000 per Salesforce license on Enterprise Edition, per the API limits page. The same page says "API calls made from installed managed packages, count against your org limit." Your integration shares that budget with every other tool the customer runs.
Worked example, arithmetic from those documented limits. An Enterprise Edition customer with 20 Salesforce licenses gets 100,000 plus 20,000 calls. That is 120,000 a day. A level 5 integration that polls five objects every five minutes makes 288 polls per object per day, which is 1,440 calls. That is 1.2% of the org's allocation. Poll every minute and it becomes 7,200 calls, or 6%, before a single record changes. A level 6 integration on Change Data Capture spends nothing on polling and only calls the API to write back. The customer's admin sees that difference in their API usage report.
HubSpot sets the ceiling per installed account rather than per day. Its usage guidelines say "each HubSpot account that installs your app is limited to 110 requests every 10 seconds," and the API limit add-on does not raise it for marketplace apps. A backfill of 50,000 contacts with one request per record would take at least 76 minutes at that rate. Batch endpoints and webhooks are the documented ways around it.
Monitoring is the other per customer cost. At level 4 and above, a broken connection in one org looks like missing data to that customer and to nobody else. Appnigma's integration infrastructure is built around that, to "Monitor each customer's connections, identify issues, and move fixes through the same review and release process."
What changes when you list on AppExchange or the HubSpot Marketplace
A marketplace listing on AppExchange or the HubSpot App Marketplace sits on top of API, event and experience level integration. It does not replace any of them. AgentExchange is the current name for AppExchange in Salesforce's ISV docs. The security review guidelines say managed packages and Salesforce Platform API solutions distributed there "must pass our security review." That includes an API-only integration, not just a native app.
Passing review also widens your reach. The API access page says "API access isn't normally supported in Group and Professional Edition orgs," and that after your app passes security review "you're eligible to use some APIs for building composite applications." A level 5 integration that never goes through review can't reach those customers at all.
HubSpot's listing requirements ask for OAuth as "its sole authorization method" and "at least three active, unique installs." Certification comes later and needs six months listed and 60 active installs, per the certification page. Appnigma's marketplace apps service builds the native app and adds "marketplace listing preparation, and review support." A listing helps buyers find and evaluate the app, but as that page says, "it is not a promise of inbound leads."
Do you need to reach level 9?
No SaaS product needs a separate level 9, and most of what gets sold as intelligent integration is event driven integration with good operations. Automatic retries, dead letter handling and alerts when a customer's token expires are reliable engineering, not a separate tier. On Salesforce, the Fire and Forget page warns that "The event bus is a distributed system and doesn't have the same guarantees as a transactional database." Your service still has to handle duplicates and gaps.
The right target depends on the buyer. A mid-market customer on HubSpot Professional may be happy with level 5 and a CSV fallback. An enterprise Salesforce customer who asks for your data on the account page is asking for level 8, and you can't get there without a packaged app. Skipping levels is fine. Building level 8 without the event and monitoring work of level 6 is the expensive version.
Mistakes SaaS teams make moving up the levels
- Treating a one-customer connector as a product. Each point to point build adds a variant to maintain. By the tenth, releases need a test pass per customer.
- Polling where an event exists. Polling five objects every minute uses 6% of a 20 license Enterprise org's daily API allocation. Change Data Capture and webhooks spend almost none.
- Starting new work on PushTopic. Salesforce calls it legacy and "provides limited support" for it. Use Change Data Capture or platform events.
- Transforming data inside the customer's org. Salesforce's middleware terms page says transformation "can be coded in Apex, but we don't recommend it due to maintenance and performance considerations." Keep mapping and queuing in your backend.
- Locking your component API too early. Once a packaged Lightning Web Component is released, "the package developer can't remove configuration targets or a public (@api) property," per the LWC packaging page. Expose only what you're ready to support for years.
- Planning the listing after the build. Security review on Salesforce and the install minimum on HubSpot both add time after the code is done. Put them in the plan from the start.
Frequently Asked Questions
What are the 9 levels of integration?
They run from manual and file based integration through database and point to point links to API based and event driven integration. Process, experience and intelligent integration sit at the top. It is Appnigma's model, not a published standard. The formal OSIMM model has seven levels.
Are the 9 levels of integration the same as Dan Siegel's nine domains?
No. Siegel's nine domains of integration come from interpersonal neurobiology and describe the mind and relationships. The software ladder shares only the number and the word.
Is there an official integration maturity model?
The best known formal one is OSIMM from The Open Group, published as ISO/IEC 16680:2012 with seven levels. Salesforce and HubSpot don't define integration levels. Salesforce classifies integrations as Process, Data or Virtual in its pattern guide.
What level of integration should a SaaS company offer?
Most SaaS products need level 5 and 6 for every customer, meaning an API plus events or webhooks. Add level 8, an installed app inside Salesforce or HubSpot, when enterprise customers ask to see your data on their CRM records.
What is the difference between point to point and event driven integration?
Point to point is a custom connection between two specific systems. Event driven integration has systems publish changes as events that any subscriber can consume, which Salesforce says "decouples event message consumers (subscribers) from event message producers," per its event driven architecture page.
Can Appnigma build the higher levels for us?
Yes. Appnigma builds customer facing integrations and native Salesforce and HubSpot apps for SaaS companies. Done for you covers the build and ongoing maintenance, and marketplace apps covers the native app plus listing and review support.
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
- What Are the Four Types of Integration?
- Salesforce Integration Patterns and Best Practices
- Platform Events vs Change Data Capture
- Salesforce iPaaS or a Native App
- What a Native Salesforce Integration Is
- HubSpot Webhooks for App Developers
- Building or Buying a Two-Way Sync
Sources
- Salesforce Developers, Integration Patterns and Practices, Pattern Summary
- Salesforce Developers, Integration Patterns and Practices, Pattern Selection Guide
- Salesforce Developers, Integration Patterns and Practices, Batch Data Synchronization
- Salesforce Developers, Integration Patterns and Practices, Remote Call-In
- Salesforce Developers, Integration Patterns and Practices, Remote Process Invocation, Fire and Forget
- Salesforce Developers, Integration Patterns and Practices, Remote Process Invocation, Request and Reply
- Salesforce Developers, Integration Patterns and Practices, UI Update Based on Data Changes
- Salesforce Developers, Integration Patterns and Practices, Data Virtualization
- Salesforce Developers, Integration Patterns and Practices, Event Driven Architecture
- Salesforce Developers, Integration Patterns and Practices, Middleware Terms and Definitions
- Salesforce Developers, Streaming API, Event Comparison
- Salesforce Developers, Pub/Sub API Developer Guide
- Salesforce Developers, Data Loader Guide
- Salesforce Developers, Salesforce Developer Limits, API Request Limits and Allocations
- Salesforce Developers, ISVforce Guide, Use Managed Packages to Develop Your AgentExchange Solution
- Salesforce Developers, ISVforce Guide, Security Review Guidelines
- Salesforce Developers, ISVforce Guide, API Access in Group and Professional Edition Orgs
- Salesforce Developers, Lightning Web Components, Add Components to a Managed Package
- HubSpot Developers, Configure Webhooks
- HubSpot Developers, Webhooks API Guide
- HubSpot Developers, API Usage Guidelines and Limits
- HubSpot Developers, Legacy Apps Overview
- HubSpot Developers, App Marketplace Listing Requirements
- HubSpot Developers, Applying for App Certification
- HubSpot Knowledge Base, Import Records
- HubSpot Knowledge Base, Connect the Snowflake Data Share
- The Open Group, OSIMM Version 2, Part 2 (archived copy)
