Skip to contentIntroducing the Integration Factory
Back to Blog
Integration

What Programs Integrate With Salesforce, and How Yours Can Too

Feb 2, 2026
ATAppnigma Team
What Programs Integrate With Salesforce, and How Yours Can Too

Thousands of programs integrate with Salesforce. Salesforce's marketplace listed "10,000 Salesforce apps" when it relaunched as AgentExchange (formerly AppExchange) in April 2026, per the Salesforce newsroom, and many more connect through the API without a listing. What separates them is where the integration runs. Some install inside the customer's org as a managed package. Others call Salesforce APIs from their own servers, ride on a middleware connector or let Salesforce read their data in place, and that choice decides which customers can use them.

If you run a SaaS company, this question usually reaches you as "does it work with Salesforce?" from an enterprise buyer. The route you choose decides which customers can use the integration, whose API budget it spends and whether you can list it on the marketplace. Appnigma builds that answer for SaaS companies. Our marketplace apps team ships "your product, inside Salesforce or HubSpot" with "marketplace listing preparation, and review support." Teams that want their own engineers on the integration can deploy integrations, faster on Appnigma's infrastructure. If you're a Salesforce admin shopping for tools, read how an admin vets and installs an AppExchange app instead.

Updated October 2026. Checked against Salesforce's REST API, ISVforce, Integration Patterns and App Limits guides. The earlier version listed program categories with no sources and used two retired product names (Pardot and Azure Active Directory). It also said nothing about the Spring '26 connected app restriction, edition rules for API access or the API budget an integration spends. All three are added here, with the AgentExchange rename.

Program categories and how each one usually connects

Salesforce integrations cluster into a handful of software categories, and each category moves a different kind of data. The examples below are programs with Salesforce integrations on the market. The last column is the pattern each category tends to need, named after Salesforce's Integration Patterns pattern summary.

CategoryExamplesData that movesPattern it usually needs
Marketing automationMarketing Cloud Account Engagement, HubSpot, Marketo, MailchimpLeads, campaign members, engagementRemote Call-In plus change events
Support and helpdeskZendesk, ServiceNow, Freshdesk, IntercomCases, contacts, conversation historyTwo-way sync, UI update on data change
ERP and accountingSAP, Oracle NetSuite, Microsoft Dynamics 365, Sage IntacctOrders, invoices, payment statusBatch Data Synchronization or Data Virtualization
Data warehouses and ETLSnowflake, Google BigQuery, Amazon Redshift, FivetranBulk record extracts and change streamsBatch Data Synchronization
Telephony and contact centerAmazon Connect, Twilio, Genesys Cloud, RingCentralCall records, screen popsRemote Process Invocation
IdentityOkta, Microsoft Entra ID, Ping IdentitySign-in and user provisioningSAML or OpenID Connect, not data sync
CollaborationSlack, Microsoft Teams, Google WorkspaceNotifications, meetings, filesFire and Forget callouts

For a vendor, the category predicts the cost of the integration more than its features do. Warehouse and ETL programs read whole objects, so they live on Bulk API 2.0 and change events, and a careless backfill shows up in the customer's API usage. Support and marketing programs write back into records sales reps edit, so field ownership and conflict rules take most of the build time. Identity programs move no records at all. If your product sits in a category where buyers expect two-way sync, they will judge you against the incumbents' depth, not against the fact that you connect.

Two names changed since most lists were written. Pardot is now Account Engagement, and the Metadata API reference calls it "Account Engagement, formerly known as Pardot." Microsoft says it "renamed Azure Active Directory (Azure AD) to Microsoft Entra ID" on its rename page, and existing Salesforce sign-in setups kept working.

Five routes a program uses to connect to Salesforce

Salesforce sorts marketplace solutions into two main types on its solution types page. A Salesforce App is installed into the org, and a Salesforce Platform API solution "interacts with the Salesforce Platform by using REST API, SOAP API, or other Platform APIs." Most integrations fall into one of five routes under those two types.

1. An app inside the org. A managed package (a versioned bundle of objects, code and UI that the vendor upgrades) puts your fields, flows and Apex into the customer's org. Code in the package can call your API through a Named Credential, which "specifies the URL of a callout endpoint and its required authentication parameters in one definition," per the Apex Developer Guide. Salesforce users work with your data on the record page instead of in a second tab.

2. Your servers calling Salesforce APIs. Your backend authenticates to each customer org with OAuth and reads or writes through REST. Our guide to connecting your product to many customer orgs with OAuth covers that setup. For volume, Salesforce says "Any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0," per the Bulk API 2.0 guide.

3. Events pushed out of Salesforce. Instead of polling, your service subscribes to changes. Change Data Capture lets you "receive near-real-time changes of Salesforce records," and Pub/Sub API is the single gRPC interface for publishing and subscribing to platform events and change events.

4. A middleware connector. An iPaaS such as MuleSoft, Boomi or Workato holds the connection and the mapping. That works well for one company joining its own systems, and it means each of your customers depends on a connector you don't own. The trade-offs are in native integration vs an iPaaS like MuleSoft or Zapier.

5. Salesforce reading external data in place. With Salesforce Connect, "Salesforce Connect maps data tables in external systems to external objects in your org," per the Data Virtualization pattern. The customer usually configures it for a system like SAP. Data 360 (formerly Data Cloud) has its own connector catalog for bringing outside data into profiles.

A SaaS product shipping to many customers usually combines the first three. The package gives users the native screens, your backend does the heavy sync, and change events keep the two current.

What a customer's org needs before any integration works

API access depends on the customer's edition. Salesforce's supported editions page says "API access is enabled by default in Enterprise, Performance, Unlimited, and Developer Edition orgs. Professional Edition orgs can add API access as an add-on." Call an org without it and Salesforce returns API_DISABLED_FOR_ORG.

The connecting user matters too. That same page says the user needs the API Enabled permission. It also describes the Salesforce Integration user license, which limits system-to-system users "to API-only operations," so a sync doesn't occupy a paid seat meant for a person.

Group and Professional Edition customers are where the routes split. The ISVforce guide says 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." The standard Data SOAP and REST APIs qualify, and Bulk API 2.0 remains unavailable. A program connecting from its own servers without a reviewed partner app can't reach a Professional Edition customer who hasn't bought the API add-on. A reviewed app can.

What your integration costs a customer's daily API budget

Every call your product makes comes out of a pool the whole org shares. The API request limits page sets the 24-hour allocation at "100,000 + (number of licenses x calls per license type)" plus any purchased add-ons. Enterprise and Professional with API get 1,000 calls per Salesforce license, and Unlimited and Performance get 5,000. The same page says "API calls made from installed managed packages, count against your org limit."

Worked example, our arithmetic from those figures. An Enterprise customer with 50 Salesforce licenses gets 150,000 calls per day (100,000 plus 50 x 1,000). The same org on Unlimited gets 350,000. A sync that polls one object every 5 minutes spends 288 calls a day, which is cheap. A sync that writes 10,000 changed records one call per record spends 10,000 calls. That is about 7% of the Enterprise pool before the customer's other tools take their share. A Composite request "counts as a single call toward your API limits," per the Composite resource page, and change events replace polling entirely. Those two choices decide whether your integration is the one an admin blames when the org hits its limit.

Are connected apps still how programs connect to Salesforce?

Existing ones still work, and new ones aren't the default anymore. The connected apps page says "Connected apps creation is restricted as of Spring '26. You can continue to use existing connected apps during and after Spring '26." It recommends external client apps instead.

An external client app (ECA) is the OAuth identity a customer authorizes when your program connects. Salesforce calls ECAs "the new generation of connected apps, designed to improve security and solve packaging and distribution issues," per the Mobile SDK guide. They "can be packaged in first-generation managed packages or second-generation managed packages," according to the second-generation packaging guide. For a second-generation package, Salesforce tells ISVs to define the ECA in their partner business org, per the packageable components list. Tutorials written before 2026 that start with "create a connected app" now need this step swapped. The differences are laid out in connected app vs external client app.

Native app, API integration or connector for a SaaS product

The three options answer "does it work with Salesforce?" in different ways, and enterprise buyers notice the difference during evaluation.

What the buyer checksNative app (managed package)API integration from your backendThird-party connector
Where users see your dataOn Salesforce record pagesIn your product, synced into fieldsWherever the connector maps it
Group or Professional Edition customersData APIs available after security reviewOnly orgs with API accessDepends on the connector vendor
Public listing on AgentExchangeYes, after security reviewYes, as a Platform API solution after reviewListed by the connector vendor, not you
Who ships fixesYou, through package upgradesYou, on your serversThe connector vendor
Who the customer calls when it breaksYouYouOften both of you

Any public listing goes through review. Salesforce says managed packages and Salesforce Platform API solutions "must pass our security review" to be distributed on AgentExchange, in its security review guidelines. Free apps go through it too and only skip the fee, per How the Security Review Works. A listing helps buyers find and evaluate you, but it is not a promise of inbound leads.

For most SaaS companies selling to enterprise, the native app plus a backend sync is the answer that holds up in a security questionnaire. A connector can be a fast first step, and it moves the support relationship and the release schedule to someone else. The four ways a SaaS product can reach a customer's Salesforce org go deeper on that choice.

Mistakes that turn "yes, we integrate" into a support ticket

  • Testing in one Developer Edition org. Developer Edition has API access by default, so the first Professional Edition customer meets API_DISABLED_FOR_ORG in production.
  • Starting from a connected app tutorial. New connected apps are restricted since Spring '26. Build the OAuth flow on an external client app from the start.
  • One API call per record. A large backfill can take a visible share of the customer's daily pool. Use Bulk API 2.0 for loads over 2,000 records and Composite or change events for steady sync.
  • Running the sync as a named employee. When that person leaves and their user is frozen, the integration stops. An Integration user license keeps the sync on an API-only system user.
  • Old product names in your docs and listing. Buyers search for Account Engagement and Microsoft Entra ID now. Docs that say Pardot or Azure AD look unmaintained.

Frequently Asked Questions

Does a Salesforce integration need a managed package?

No. A program can integrate purely through the API from its own servers. A managed package is what puts your screens and logic on the customer's record pages, and a reviewed partner app is what reaches Group and Professional Edition orgs without the API add-on.

Do API calls from an installed package count against the customer's limit?

Yes. Salesforce's limits page says "API calls made from installed managed packages, count against your org limit," so your package shares the pool with every other tool in the org.

Can a program integrate with Salesforce Professional Edition?

Yes, with conditions. The org needs the API add-on, unless the program is a partner app that has passed security review and uses the standard Data SOAP or REST APIs.

Can we still create a connected app for our integration?

Not by default. Creation has been restricted since Spring '26, existing connected apps keep working, and Salesforce points new integrations to packageable external client apps.

Can Appnigma build our Salesforce integration?

Yes. Appnigma's marketplace apps service builds the native Salesforce app with listing preparation and review support. The done-for-you service assigns an integration engineer who builds and maintains customer integrations so your team can "build your product."

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.

Sources

  1. Salesforce Newsroom, Salesforce Headless 360 announcement
  2. Salesforce Developers, Integration Patterns and Practices, Pattern Summary
  3. Salesforce Developers, Integration Patterns and Practices, Data Virtualization
  4. Salesforce Developers, Metadata API Developer Guide, PardotSettings
  5. Microsoft Learn, New name for Azure Active Directory
  6. Salesforce Developers, ISVforce Guide, AgentExchange Solution Types
  7. Salesforce Developers, Apex Developer Guide, Named Credentials as Callout Endpoints
  8. Salesforce Developers, Bulk API 2.0 and Bulk API Developer Guide
  9. Salesforce Developers, Change Data Capture Developer Guide
  10. Salesforce Developers, Pub/Sub API
  11. Salesforce Developers, Data 360 Connectors and Integrations
  12. Salesforce Developers, REST API Developer Guide, Supported Editions and Required Permissions
  13. Salesforce Developers, ISVforce Guide, API Access in Group and Professional Editions
  14. Salesforce Developers, Salesforce Developer Limits and Allocations Quick Reference, API Request Limits and Allocations
  15. Salesforce Developers, REST API Developer Guide, Composite
  16. Salesforce Developers, Security Implementation Guide, Connected Apps
  17. Salesforce Developers, Mobile SDK Development Guide, Create an External Client App
  18. Salesforce Developers, Second-Generation Managed Packaging, Connected Apps and External Client Apps
  19. Salesforce Developers, Second-Generation Managed Packaging, Packageable Components
  20. Salesforce Developers, ISVforce Guide, Security Review Guidelines
  21. Salesforce Developers, ISVforce Guide, How the Security Review Works
  22. Salesforce Developers, AppExchange Install Guide, What Is AgentExchange

All Blogs

Bring the customer requirements and your current setup. Get a clear scope and delivery timeline to take back to them.