The Salesforce Exchange integration apps that install in days and keep working through releases share a handful of build decisions. Authentication ships inside the package, permissions arrive as permission sets, and the code stays pinned to the API version it was tested on. Upgrades reach customer orgs on a schedule the vendor controls. None of that shows on a listing page, and all of it shows up in a customer's sandbox.
If you are a SaaS company whose enterprise customers ask for a native Salesforce integration, this is the part of the deal you own. You build the package, pass the security review and publish the listing. Then each customer installs it in their own org, and Salesforce ships three major releases a year on top of it. Appnigma's marketplace apps team builds that native app for SaaS companies, with listing preparation and review support. Admins comparing apps to install should read the checklist a customer's admin runs on your app. If you searched for Salesforce's Microsoft Exchange email sync, Salesforce Help calls Einstein Activity Capture "the long-term solution" and says Lightning Sync retires in 2027, per Move from Lightning Sync to Einstein Activity Capture.
Updated October 2026. Checked against Salesforce's ISVforce Guide, the packaging guides, the Named Credentials guide, the REST API end-of-life policy and the Apex Developer Guide. The earlier version of this page described cookie settings as app requirements, cited a listing count no Salesforce page uses, and said integrations run without data caps. Salesforce counts every packaged API call against the customer's org limit. This update replaces those claims and adds how integration apps are packaged, reviewed and kept stable across releases.
Three ways an integration reaches AppExchange
A SaaS integration can reach Salesforce customers as an installed package, as an API listing, or through an iPaaS vendor's connector. Salesforce now calls the marketplace AgentExchange. It offers "three different types of listings: Packaged Solution, API, and Consultant listings," per Select an AgentExchange Listing Type. The same page says "you can't change the listing type after it's created." For an integration, the choice is mostly between the first two. An API solution is one "that interacts with the Salesforce Platform by using REST API, SOAP API, or other Platform APIs," per AgentExchange Solution Types. Both have to pass security review before public distribution.
| Packaged Solution (managed package) | API listing | iPaaS connector | |
|---|---|---|---|
| Where your logic runs | Inside each customer org, plus your servers | On your servers only | On the iPaaS vendor's cloud |
| What the customer installs | A namespaced package | Nothing, they authorize your app | The iPaaS vendor's own connector |
| What Salesforce reviews | Package code scan plus your external endpoints | Your endpoints, a Developer Edition org and DAST scans | Your app is not the reviewed party |
| What a release can change | Packaged code keeps its saved API version | The API version in your request URLs | Handled by the iPaaS vendor |
| How fixes ship | Package upgrades, pushed or installed | Deploy your own service | The iPaaS vendor's release cycle |
| In-org UI, triggers, custom objects | Yes | No | No |
The required-materials table for an "API Only" submission lists a Developer Edition org, credentials for external components and DAST scan reports, and no managed package, per Required Materials for Security Review Submission. That makes an API listing the lighter build. It also means nothing of yours lives in the customer's org, so a customer who wants your data on a record page, in a flow or in a report needs the package. Choose with the listing type rule in mind, because the choice is permanent. Our explainer on the three AgentExchange listing types covers the customer side, and native integration vs an iPaaS connector covers when a connector is the better choice.
What makes an integration app install in days instead of weeks
Most of the setup time on an integration app goes into authentication and permissions, and both can ship in the package. Since Spring '26, Salesforce says "connected apps creation is restricted," while existing connected apps keep working, per Connected Apps. The packaging guide recommends the replacement. "External Client Apps are the new and improved generation of connected apps," and they can be packaged in first- or second-generation managed packages, per Package Connected Apps in 2GP. ISVs packaging one in 2GP "should instead define the External Client App in their PBO (Partner Business Org) Dev Hub," per Components Available in Second-Generation Managed Packages. A packaged External Client App means the customer's admin never registers an OAuth app by hand.
Outbound calls from the package to your service work the same way. Named credentials and external credentials can travel in a managed 2GP, but "external credential certificates and access tokens aren't packageable," per Package Named Credentials. The Named Credentials Packaging Guide gives the remaining step. "Use the Connect API to populate the external credential's principal in the target org." The same guide says upgrades don't overwrite those principals, so a customer authorizes once rather than once per version. Our Named Credentials guide shows the packaging pattern in detail.
Permissions are the other half. "Subscribers must assign packaged permission sets after installing the package," per Permission Sets and Profile Settings in Packages. Ship one permission set per role and name them on your setup page, and that step takes minutes. A post-install script can seed default settings, since an InstallHandler class "enables custom code to run after a managed package installation or upgrade," per the InstallHandler Interface. Keep it small. "If the script fails, the install/upgrade is aborted," per Run Apex on Package Install/Upgrade. A script that calls your API during install fails whenever your service or the customer's network says no.
Edition is the last surprise. "API access isn't normally supported in Group and Professional Edition orgs. However, after your app passes the security review, you're eligible to use some APIs," per API Access in Group and Professional Editions. Bulk API 2.0 stays unavailable there. A sales team that promises Professional Edition customers a bulk sync before review has promised something the platform won't run.
Why do some AppExchange apps break after a Salesforce release?
Packaged Apex rarely breaks on a release by itself, because each class runs at the API version it was saved with. "This version is also the version of Apex associated with the class or trigger," per Setting the Salesforce API Version for Classes and Triggers. The clearest recent proof is the security default. "In API version 67.0 and later, Apex runs in user context by default," per Apex Versioned Behavior Changes. For 66.0 and earlier, "system mode is the default." A class saved at 66.0 behaves the same after the release. The break comes when a developer bumps the class to 67.0 for a new feature and a query that used to see every record now respects the running user's sharing. The same page says WITH SECURITY_ENFORCED can't be used in SOQL from 67.0 on, so that bump fails to compile until those queries move to WITH USER_MODE.
The vendor-hosted half of an integration is where releases actually bite. Salesforce supports "each API version for a minimum of 3 years from the date of first release" and notifies customers "at least 1 year before support for the version ends," per the REST API End-of-Life Policy. The same page lists versions 21.0 through 30.0 as retired since Summer '25, and versions 31.0 through 40.0 as "deprecated and unsupported from Summer '27" and "retired from Summer '28." A retired version answers with 410:GONE. No Salesforce page promises an API that never breaks. What it promises is a support window and a year of notice, and the vendor has to act on that notice. An integration service that still calls /services/data/v39.0/ works today, gets a deprecation notice, and stops on a date the customer did not choose. Search your own codebase for hardcoded version strings before a customer's security team finds them in a log.
Authentication has its own calendar. SOAP API login() is being retired "in the Summer '27 release," per login(). The Winter '27 release notes add that "in Summer '27, Salesforce is ending support for connected apps," per Migrate All Connected Apps to External Client Apps. An integration that still signs in with a username and password through SOAP, or depends on a connected app it never migrated, has a 2027 deadline in every customer org at once.
Managed packages add one more protection. "Manageability rules determine whether you, or the subscriber, can edit or remove components after the package version is installed," per How Manageability Rules and Ancestry Impact Upgrades. A customer admin can't edit your packaged Apex into a broken state, and your own build fails if you try a change that would break their install.
How fixes reach every customer org after a release
A fix only helps once it is in the customer's org, and for a package that means an upgrade. "The push upgrade feature is only available to first- and second-generation managed packages that have passed the AgentExchange security review," per Push a Package Upgrade for Second-Generation Managed Packages. Before review, every customer installs each new version by hand, and a release-day fix reaches only the admins who read your email.
Timing matters as much as the mechanism. Salesforce's Push Upgrade Best Practices say "it might be better to wait 3-4 weeks after a major Salesforce release before you push major upgrades." Customers also get to test first. The 1GP version of the same guidance says to give them "a week or more to test, validate, and fix in the sandbox environment before you push to their production organizations." So a vendor that wants upgrades to land smoothly runs its own regression suite against preview sandboxes before each release, then ships a patch only if something changed. Major feature upgrades wait until the release settles. Our post on push upgrades across customer orgs covers how enterprise customers can restrict them.
What security review checks on an integration app
For most integration apps the larger part of the review sits outside Salesforce. "When you perform security scans, include all external endpoints that run independently of the Salesforce platform," per Test Your Entire Solution. An endpoint is in scope when "Salesforce data is transferred to or from the endpoint" or when it authenticates the user, and the page sums it up as "wherever the customer or data goes is in scope." Your sync workers, webhook receivers and admin console all count.
Inside the package, the review looks hard at how you store the customer's secrets. "When storing a secret in a custom object, such as an API key, encrypt it," per Store Sensitive Data Insecurely. The key itself belongs "in a protected custom setting or a protected custom metadata API field." For data access, Salesforce's guidance is "Enforce FLS and CRUD directly, using WITH USER_MODE," per Secure UI Bundles for AgentExchange.
Two points keep expectations honest with buyers. Passing review is not a warranty, since "Salesforce makes no guarantees regarding the quality or security of any Partner Application," per Security Requirements for ISV Partners. Review also repeats, and "security review fees apply" to periodic reviews, per Periodic Reviews. Our security review checklist walks through the submission itself.
What a sync costs the customer's daily API budget
An integration app spends the customer's API allocation, not its own. "API calls made from installed managed packages, count against your org limit," and the limit is enforced "against the aggregate of all API calls made to the org in a 24-hour period," per API Request Limits and Allocations. The same page gives the Enterprise Edition example. "For an Enterprise Edition org with 15 Salesforce licenses, the request limit is 115,000 requests."
Here is arithmetic from that figure, not a customer measurement. An API-listed integration that checks 20 objects for changes every 5 minutes makes 5,760 calls a day, about 5% of that org's budget, before it moves a single record. Checking every minute makes 28,800 calls, a quarter of the budget. That budget is shared with every other integration the customer runs. The small org is the one that notices first, and it is often the pilot customer. Batched requests and event-driven sync keep the number flat as customers grow. Our guide to Salesforce API rate limits for native integrations covers the patterns.
Mistakes that make an integration app stall at install or break later
These show up in a customer's sandbox or on release weekend, usually after the deal is signed.
- Building a new connected app after Spring '26 instead of a packaged External Client App.
- Shipping an access token, certificate or API key in the package instead of filling the principal after install.
- A post-install script that calls your service, so an outage on your side aborts the customer's install.
- Hardcoded API versions in the vendor-hosted service, with no owner for the deprecation notices.
- Bumping every class to the newest API version in one release without retesting sharing behavior.
- Choosing an API listing for speed, then learning the customer needs record-page UI that only a package can add.
- Pushing a major upgrade in the week after a Salesforce release, or at the customer's quarter-end.
Who builds and maintains an AppExchange integration app?
Most SaaS teams can write the integration itself. Fewer have shipped a managed package through security review and kept it working across customer orgs and three releases a year. Appnigma builds that for SaaS companies. The marketplace apps service describes it as "your product, inside Salesforce or HubSpot," with the native app, listing preparation and review support. The page says the team is "Built by ex-Salesforce engineers," and that "a listing supports discovery and evaluation, but it is not a promise of inbound leads." Salesforce controls review timing. For integrations you want built and maintained for you, done-for-you integrations pair you with a named integration engineer, and fixes arrive as pull requests for your review. Teams that want their own engineers in control use integration infrastructure to deploy and monitor each customer connection. If you are still deciding between an app and a connector, start with native Salesforce app or off-platform connector.
Frequently Asked Questions
Which AppExchange apps stay stable during Salesforce platform updates?
Apps whose packaged code keeps its saved API version and whose vendor services stay on supported API versions. Salesforce supports each API version for at least 3 years and gives a year of notice.
Can an integration be listed on AppExchange without a managed package?
Yes. An API listing needs no package, but it still passes security review, including DAST scans of your endpoints. The listing type can't be changed later.
How do AppExchange integration apps set up in days instead of weeks?
They package an External Client App, named and external credentials and per-role permission sets. The admin then authorizes once and assigns permission sets.
Do AppExchange integration apps use the customer's API limit?
Yes. Calls from installed managed packages count against the org's daily allocation, which is 115,000 requests for a 15-license Enterprise Edition org.
Can Appnigma build and list a Salesforce integration app for us?
Yes. Appnigma's marketplace apps service builds the native app and supports listing preparation and review. Salesforce controls review timing and approval.
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 Is a Best Practice When Using AppExchange?
- What Is Salesforce AppExchange?
- What Is the Salesforce App Marketplace and How to Launch There
- Salesforce Managed Package Guide
- Push Upgrade Customization for Managed Packages
Sources
- Salesforce Developers, Select an AgentExchange Listing Type
- Salesforce Developers, AgentExchange Solution Types
- Salesforce Developers, Required Materials for Security Review Submission
- Salesforce Developers, Connected Apps
- Salesforce Developers, Package Connected Apps in 2GP
- Salesforce Developers, Components Available in Second-Generation Managed Packages
- Salesforce Developers, Package Named Credentials
- Salesforce Developers, Named Credentials Packaging Guide
- Salesforce Developers, Permission Sets and Profile Settings in Packages
- Salesforce Developers, InstallHandler Interface
- Salesforce Developers, Run Apex on Package Install/Upgrade
- Salesforce Developers, API Access in Group and Professional Editions
- Salesforce Developers, Setting the Salesforce API Version for Classes and Triggers
- Salesforce Developers, Apex Versioned Behavior Changes
- Salesforce Developers, REST API End-of-Life Policy
- Salesforce Developers, login()
- Salesforce Help, Migrate All Connected Apps to External Client Apps (Release Update)
- Salesforce Developers, How Manageability Rules and Ancestry Impact Upgrades
- Salesforce Developers, Push a Package Upgrade for Second-Generation Managed Packages
- Salesforce Developers, Push Upgrade Best Practices
- Salesforce Developers, Test Your Entire Solution
- Salesforce Developers, Store Sensitive Data Insecurely
- Salesforce Developers, Secure UI Bundles for AgentExchange
- Salesforce Developers, Security Requirements for ISV Partners and AgentExchange Solutions
- Salesforce Developers, Periodic Reviews
- Salesforce Developers, API Request Limits and Allocations
- Salesforce Help, Move from Lightning Sync to Einstein Activity Capture
