Yes, a SaaS company can put a native Salesforce app in front of customers without a public AppExchange listing. You release a second-generation managed package and give each customer an install link and an installation key. That private route sits between an iPaaS connection, which keeps your logic outside Salesforce, and a listed app that has passed Salesforce's security review. What decides between the three is not whether you want a listing. It is whether you need push upgrades, your own Apex limits and Professional Edition customers, because those come only with the review.
This guide is for founders, CTOs and product leaders whose enterprise customers asked for the integration inside their own Salesforce org. It compares the three routes on what each one costs in the customer's org, what the private install involves, and the mistakes that show up after the fifth or tenth customer installs. Appnigma's marketplace apps work exists for this decision. It puts "your product, inside Salesforce or HubSpot" as a native app with review support, and our done for you delivery builds and maintains the integrations your customers need when the logic belongs in your backend.
Updated October 2026. Checked against Salesforce's Second-Generation Managed Packaging guide, the ISVforce guide and the Salesforce limits cheat sheet. The earlier version said a native app removes reliance on API limits and that a managed package gives easy updates without mentioning the review. Neither matches Salesforce's docs. This update corrects both and adds the private install path, what skipping the review costs, and when an iPaaS is the better choice.
Three ways to get your integration into a customer's Salesforce org
An iPaaS connection, a private managed package and a listed managed package each put the integration logic in a different place. That placement decides who owns authentication, upgrades and limits in the customer's org. This comparison uses Salesforce's documented behavior for each route.
| iPaaS connection | Private managed package | Listed, reviewed managed package | |
|---|---|---|---|
| Where the logic runs | The iPaaS runtime, outside Salesforce | Apex, flows and components in the customer's org | Apex, flows and components in the customer's org |
| How it reaches the customer org | OAuth into each org, then REST, SOAP or Bulk calls | Install link plus installation key | AppExchange listing or install link |
| Counts against the org's daily API allocation | Every inbound call | Only the calls your backend makes into the org | Only the calls your backend makes into the org |
| Per-transaction Apex limits | Not applicable | Shared with the customer's own code | Its own set for most limits |
| Push upgrades to installed orgs | Not applicable | Not available | Available after enablement |
| Group and Professional Edition API access | Needs the org to have API access | Not available | Available with an API token |
| Discoverable by other customers | No | No | Yes, unless made private |
Two rows need the source text. Salesforce's API Request Limits and Allocations page counts REST, SOAP, Bulk API and Bulk API 2.0 calls toward the allocation, whoever makes the call. On the limits row, the Apex Governor Limits page says that "certified managed packages, managed packages that have passed the security review for AppExchange, get their own set of limits for most per-transaction limits."
What a private managed package install involves
A private install still uses the full packaging toolchain and a partner setup. Salesforce's Before You Create Second-Generation Managed Packages page says to "enable Dev Hub and Second-Generation Managed Packaging in your Partner Business Org (PBO)," and to register a namespace. Then you promote a second-generation managed package (2GP) version to released. Salesforce says that "only released package versions can be listed on AgentExchange and installed in customer orgs," and a release needs "a minimum 75% code coverage," per Prepare to Distribute Your Second-Generation Managed Package. AgentExchange is the name Salesforce's partner docs now use for AppExchange.
The installation key is what keeps the package private. Per Package Installation Key for Second-Generation Managed Packages, "package creators provide the key to authorized subscribers so they can install the package," and nothing about the package is shown until the key is entered. The commands are short, and the managed package guide covers the full release workflow.
Create a version protected by a key, then promote it to released:
sf package version create --package "Acme Sync" --installation-key "$ACME_KEY" --code-coverage --wait 30
sf package version promote --package "Acme [email protected]"The customer's admin installs it with the same key:
sf package install --package 04t... --installation-key "$ACME_KEY" --target-org customer-prodMost customer admins install from a browser instead. Promoting a version prints an install link in the form https://login.salesforce.com/packaging/installPackage.apexp?p0=04t..., per Release a Second-Generation Managed Package. "Anyone with the URL and a valid login to a Salesforce org can install the package," per Use a URL to Install a Second-Generation Managed Package, so the key is the real gate. Plan who sends it and how. One key per version is the default, which means a key you emailed to one customer also opens that version for anyone they forward it to.What you give up by skipping the security review
Skipping the review saves weeks before the first install. The costs arrive later, once several customers run your package, and four of them are documented.
The customer's admin sees a warning at install. Salesforce shows a notification for any managed package that "has never been through security review or is under review," and the admin "must confirm that they understand that the package isn't authorized for distribution," per Install Notifications for Unauthorized Managed Packages. An enterprise security team reads that screen. Tell the customer before they see it, and say when you plan to submit for review.
Upgrades become each customer's job. Push upgrades let you move installed orgs to a new version without asking the admin, but "you can push upgrades to packages that have passed AgentExchange security review only," per Push a Package Upgrade for Second-Generation Managed Packages. Without the review, a bug fix reaches a customer only when their admin installs the new version. Ten customers on four versions is a support load most teams don't plan for.
Your Apex shares the customer's limits. An uncertified package's code counts against the same per-transaction limits as the customer's own triggers and flows. Here is a worked example from the documented limits, not a measured customer. The synchronous DML limit is 150 statements per transaction. If a customer's existing Account triggers already use 130 of them when your package's trigger runs on the same save, your code has 20 left. A certified package would get "its own 150 DML statements," in the words of the Apex Governor Limits page. Heap size and CPU time stay shared either way. Read more: Governor Limits for Certified Managed Packages
Professional Edition customers are out of reach. "API access isn't normally supported in Group and Professional Edition orgs." The exception is an API token that comes "after your app passes the security review," per API Access in Group and Professional Editions. If your backend needs to call into a Professional Edition org, the private route can't serve that customer.
Smaller costs follow the same rule. A package that isn't security reviewed gets no free Platform Cache, because "the Provider Free capacity resets to zero," per Set Up a Platform Cache Partition with Provider Free Capacity.
A private AppExchange listing is not a workaround for any of this. Salesforce says private listings can't be found "by browsing or searching AppExchange" but stay reachable by URL, and "you can make a listing private only if it's publicly available," per Make Your AppExchange Listing Private. That path starts with a public, reviewed listing, which raises its own question of whether a public AppExchange listing is worth it.
Does a native Salesforce app avoid API limits?
No. A native app changes where the calls come from, not whether the org counts them. Every REST, SOAP and Bulk API call your backend makes into the customer's org draws on the same 24-hour allocation an iPaaS would use. For Enterprise Edition the allocation is "100,000 + (number of licenses x calls per license type) + purchased API Call Add-Ons." Each Salesforce license adds 1,000 calls, per API Request Limits and Allocations.
Here is what that means for one customer, worked from the documented formula. An Enterprise org with 200 Salesforce licenses gets 300,000 calls a day. A sync that polls four objects every five minutes makes 1,152 calls a day, which is small. A sync that reads every changed Opportunity one record at a time during a 20,000-record import is not, and the customer's other integrations share the same pool.
What a package does change is that logic inside the org runs as Apex, which is governed by per-transaction limits instead. The Callout Limits and Limitations page covers the outbound side, and the governor limits page sets 100 callouts per transaction. Moving the "detect a change and send it" step into a trigger or flow can cut your inbound polling. It does not remove limits, and a page that promises otherwise is the one the customer's admin will quote back to you. The daily API allocation in a customer's org has its own guide.
When an iPaaS connection is the better choice
An iPaaS is the right answer more often than a vendor of native apps tends to admit. If the customer already runs MuleSoft, Workato or Boomi and has a team that owns it (see how MuleSoft, Boomi and Zapier compare with a native integration), connecting your product's API to their platform puts the integration in the hands of the people who will maintain it. If the integration only moves data and your users never need a screen, button or field inside Salesforce, a package adds packaging, versioning and install support for no visible gain. If you have two or three enterprise customers asking and are still learning what the integration should do, changing a recipe is faster than releasing a package version.
The native route earns its cost when the integration has to behave like part of Salesforce. That means record pages showing your data, actions your users run from Salesforce, logic that must run inside a save, or a security team that wants the code reviewed and installed rather than another vendor holding OAuth tokens. Appnigma's integration infrastructure covers the in-between case, where your engineers build the per-customer connections on managed auth, sandboxes and monitoring instead of on a general-purpose iPaaS.
If the integration is only for your own company's org
A company building only for its own Salesforce org, not for customers, faces a different packaging decision. Salesforce's Unlocked Packages page calls unlocked packages "especially suited for internal business apps." Unless you plan to distribute on AppExchange, Salesforce says an unlocked package is the right type for most use cases. A managed package's protections, such as hidden code and namespace locks, matter when other companies install your app. Inside your own org they mostly get in the way.
Mistakes that show up after customers install a private package
Privately installed managed packages fail in a few predictable ways, each traceable to documented Salesforce behavior and each cheaper to fix before installs than after.
- Piloting on a beta version. "Beta versions can be installed in only scratch orgs and sandboxes," and an installed beta can't be upgraded later, per Get Ready to Promote and Release a Second-Generation Managed Package Version. A customer's sandbox pilot on a beta has to be uninstalled before the released version goes in.
- Planning on push upgrades. Teams build a release cadence around pushing fixes, then learn push upgrades need the review. Decide before the second customer whether you will go through it.
- Treating the installation key as access control. The key protects a version, not a customer. Rotate it with
sf package version updatewhen a version should no longer be installable. - Assuming credentials ship ready to use. Named credentials and external credentials go into the package, but "external credential certificates and access tokens aren't packageable," per Package Named Credentials. Each customer org authenticates after install, so write that step into the install guide.
- Selling to a Professional Edition customer. Check the customer's edition during the sales process, before the package is built around API calls into their org.
- Skipping the partner setup. The License Management App "is installed in all partner business orgs," per Get Started with the License Management App, and that org is where 2GP packaging is enabled. Seat licenses and lead records for your package depend on joining the partner program, even if you never list.
Frequently Asked Questions
Can I install a Salesforce managed package without AppExchange?
Yes. A released second-generation managed package version installs from its install link or with sf package install, protected by an installation key you give to each customer.
Do I need the security review to distribute a managed package privately?
Salesforce doesn't block the install. An unreviewed package installs after the admin confirms a notice that it isn't authorized for distribution. The review is what removes that notice and brings public listing, push upgrades, separate Apex limits and Professional Edition API access.
Does a native Salesforce app use fewer API calls than an iPaaS?
It can, when logic that detects changes moves into Apex inside the org. Every call your backend still makes into the org counts toward the same daily allocation, which is 100,000 plus 1,000 per Salesforce license on Enterprise Edition.
Can Appnigma build the native Salesforce app and handle the review?
Appnigma's marketplace apps work delivers "a native app, marketplace listing preparation, and review support," and treats build and review as separate steps. Whether a first version should install privately before review is a scoping question for your situation.
Related Articles
- Salesforce iPaaS or a Native App for a SaaS Integration
- What a Native Salesforce App Is and When a SaaS Company Needs One
- Salesforce Integration Tools Compared
Sources
- Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, API Request Limits and Allocations
- Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, Apex Governor Limits
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Prepare to Distribute Your Second-Generation Managed Package
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Package Installation Key for Second-Generation Managed Packages
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Push a Package Upgrade for Second-Generation Managed Packages
- Salesforce Developers, ISVforce Guide, API Access in Group and Professional Editions
- Salesforce Developers, ISVforce Guide, Make Your AppExchange Listing Private
- Salesforce Developers, Apex Developer Guide, Callout Limits and Limitations
- Salesforce Developers, Salesforce DX Developer Guide, Unlocked Packages
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Get Started with the License Management App
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Get Ready to Promote and Release a Second-Generation Managed Package Version
- Salesforce Developers, Named Credentials Developer Guide, Package Named Credentials
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Before You Create Second-Generation Managed Packages
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Release a Second-Generation Managed Package
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Use a URL to Install a Second-Generation Managed Package
- Salesforce Developers, First-Generation Managed Packaging Developer Guide, Set Up a Platform Cache Partition with Provider Free Capacity
- Salesforce Developers, Second-Generation Managed Packaging Developer Guide, Install Notifications for Unauthorized Managed Packages
