Salesforce glue code is the custom code a SaaS company writes to connect its product to each customer's Salesforce org. It covers the OAuth connection, the field mapping, the sync logic and the error handling that keep both systems agreeing. You can't remove it. What a SaaS company decides is where that code lives and who keeps it working after each customer goes live and Salesforce ships three releases a year.
That decision usually comes up in an enterprise deal, when a buyer asks for a Salesforce integration and your team realizes every new customer org will need its own mapping. Appnigma works with B2B SaaS teams on exactly this. Our done for you delivery is built on "Build your product. We'll build the integrations," with a named integration engineer and ongoing maintenance. If you need the integration to run inside Salesforce instead, our marketplace apps work puts "your product, inside Salesforce or HubSpot" as a native app.
Updated October 2026. Checked against the Salesforce Developer Limits guide, the Apex Developer Guide, the packaging guides, the ISVforce Guide and the REST API end-of-life policy. The earlier version of this post described a drag-and-drop builder that shipped integrations as unmanaged packages and kept them current automatically. Unmanaged packages can't be upgraded by the company that publishes them, so that approach leaves every installed copy frozen. This update replaces it with what Salesforce documents about packages, API limits and the changes that make glue code need rework.
What glue code does inside a Salesforce integration
In general software, glue code is the code that makes two components work together without adding features of its own. In a SaaS company's Salesforce integration it has six jobs, and each one can differ from one customer org to the next.
| Job | What the code does | Why it differs per customer org |
|---|---|---|
| Authentication | Holds an OAuth connection and refreshes tokens | Each org authorizes separately, and admins set session and IP policies |
| Field mapping | Maps your objects to Accounts, Opportunities and custom objects | Custom fields, record types and picklist values are set by each admin |
| Change detection | Finds what changed since the last sync | Polling cost scales with how many objects each customer syncs |
| Writes and validation | Creates and updates records | Validation rules, required fields and duplicate rules reject writes that pass in another org |
| Limits and retries | Backs off and retries on limit errors | Each org has its own daily API allocation |
| API version | Calls a pinned Salesforce API version | Shared across customers, so a retirement hits every connection at once |
The mapping row is where most of the per-customer work goes. Two customers on the same Salesforce edition can store the same deal stage in different fields, and a write that succeeds in one org fails a validation rule in the other. That is why glue code is usually priced per customer and why maintaining it doesn't get cheaper as you add customers.
Why glue code grows with every customer org
Each customer org gets its own daily API allocation, and your integration spends from it. Salesforce sets the daily total for Enterprise Edition as "100,000 + (number of licenses x calls per license type) + purchased API Call Add-Ons," per API Request Limits and Allocations. The same page states that "API calls made from installed managed packages, count against your org limit," so moving the code into a package doesn't move the cost off the customer. Some AI answers say a security-reviewed package is exempt. What a reviewed package gets is its "own set of limits for most per-transaction limits" in Apex, per Execution Governors and Limits, not a separate daily API allocation.
Here is a worked example from those documented numbers, not from a customer. Take a customer on Enterprise Edition with 50 Salesforce licenses. Their org gets 100,000 plus 50 x 1,000 calls. That totals 150,000 per 24 hours. Glue code that polls six objects every five minutes makes 288 checks per object per day, which is 1,728 calls before it writes a single record. That is about 1.2% of the allocation, spent even on days when nothing changed, and it is shared with every other app the customer has connected.
Polling has an alternative. Change Data Capture publishes record changes as events, though an org can select "up to five entities, including standard and custom objects," per Select Objects for Change Notifications. An AppExchange package is treated differently. Salesforce says "the selections made by the AppExchange package in a custom channel don't count against your org's allocation," per Change Data Capture Allocations. For a SaaS company whose customers already use their five selections, that exemption is one practical reason to ship the change-detection piece as a listed package.
Long requests have their own ceiling. When too many requests of 20 seconds or more run at once, "the API returns a REQUEST_LIMIT_EXCEEDED exception code," per the same API limits page. Glue code that runs every customer's initial load in parallel against one org is the usual way to hit it. Salesforce suggests Bulk API 2.0 for "any data operation that includes more than 2,000 records," per Bulk API and Bulk API 2.0 Limits and Allocations.
Salesforce changes that force glue code rework
Glue code that nobody owns stops working on Salesforce's schedule, not yours. Four changes in the current docs each require someone to edit and redeploy every customer connection.
API version retirement. Salesforce commits to "supporting each API version for a minimum of 3 years from the date of first release," per the API End-of-Life Policy. Versions 31.0 through 40.0 are "Deprecated and unsupported from Summer '27" and "Retired from Summer '28." Retired versions return "the 410:GONE error code," so old glue code fails outright rather than slowly.
Connected app creation. "Creating connected apps is restricted as of Spring '26," per OAuth and Connected Apps. Existing connected apps keep working. New integrations are built on external client apps, which "can be packaged in first-generation managed packages or second-generation managed packages," per the 2GP guide.
OAuth controls for partner apps. Salesforce's partner security requirements add PKCE, refresh token rotation and an idle limit, and "Salesforce invalidates the idle refresh token after 30 days," per Secure Your Connected Apps and ECAs. A customer who pauses your sync for a month comes back to a dead connection unless your code handles reauthorization.
Legacy named credentials. Packaged code that calls your backend through a named credential needs the newer model, because "Legacy named credentials are deprecated and will be discontinued in a future release," per Named Credentials. Tokens also stay per customer, since "External credential certificates and access tokens aren't packageable," per Package Credentials. Our guide to connecting to many customers' Salesforce orgs with OAuth covers the per-org setup.
Can an unmanaged package replace glue code?
An unmanaged package looks like a shortcut, because it installs the same components in every org without a namespace or a security review. The catch is upgrades. Salesforce says "The developer who creates and uploads an unmanaged package has no control over the installed components, and can't change or upgrade them," per Developing and Distributing Unmanaged Packages. Its install guide puts it more plainly. "Unmanaged packages aren't upgradeable," per Prepare to Install an AgentExchange Package.
For a SaaS company that turns every install into a separate copy you can't patch. When API version 40.0 retires, each customer's admin has to edit their copy by hand. The code is also visible and editable in the customer's org, so the copies drift apart after the first admin change.
A managed package is the version Salesforce built for this. "Unlike unmanaged packages, package developers can upgrade managed packages and push these changes to subscriber orgs," and Salesforce recommends 2GP for new apps, per Managed Package Types. The same page is clear about the trade. "Preserving the backwards-compatibility of managed packages is the package developer's responsibility." Push upgrades change a customer org "without explicit consent," per Push Upgrades, and partners can let customers restrict push upgrades for their org. So someone still owns release testing for every version. Our post on how push upgrades reach installed customers walks through that release work.
Where the glue code lives in each route
A SaaS company has four common routes to a Salesforce integration, and every one of them still needs per-customer glue code. The routes differ in where that code runs and who is on the hook when it breaks.
| Route | Where the per-customer code runs | Who maintains it | Security review to list |
|---|---|---|---|
| Your own API connector | Your servers, one connection per customer org | Your engineers | Required for a listed Salesforce Platform API solution |
| Managed package (native app) | Inside each customer org, plus your backend for callouts | You, through package versions and push upgrades | Required |
| Embedded iPaaS or unified API | The vendor's platform, configured per customer | Your engineers, on the vendor's tooling | Same as an API connector |
| Done for you | Built and run by an integration partner | A named engineer at the partner | Depends on the route the partner builds |
The review column comes from Salesforce's rule that managed packages and "Salesforce Platform API solutions" on AgentExchange "must pass our security review," per Security Review Guidelines. The review follows your data out of the org. "Wherever the customer or data goes is in scope," per Test Your Entire Solution, so the backend your glue code calls is tested too.
Inside a package, the code runs under Apex limits instead of API calls. "A single Apex transaction can make a maximum of 100 callouts," with a cumulative timeout of 120 seconds, per Callout Limits and Limitations. The same page notes "You can't make a callout when there are pending operations in the same transaction," which is why packaged sync code that saves a record and then calls your backend moves the callout into a Queueable job that implements Database.AllowsCallouts, per Queueable Apex.
For named vendors in the embedded iPaaS and unified API rows, see our comparison of Salesforce integration tools. For the package route itself, see what a Salesforce native app is and how one gets built.
Mistakes that turn glue code into a support queue
These come up repeatedly when a SaaS team inherits integrations nobody owned.
- One mapping for every customer. A hard-coded field map works for the first customer and fails the first validation rule in the second. Store mapping per connection.
- Polling everything. Checking every object on a short interval spends the customer's allocation on empty results. Use change events where the object count allows.
- No owner for the API version. Nobody notices the pinned version until Salesforce returns 410 for every customer on the same day.
- Treating token expiry as an outage. Idle refresh tokens expire after 30 days for partner apps. The fix is a reconnect prompt in your product, not a support ticket.
- Shipping an unmanaged package. It can't be patched, so each fix becomes a per-customer manual edit.
- Parallel initial loads. Large backfills belong in Bulk API 2.0 jobs, not a loop of REST calls that collides with the concurrent request limit.
Who should own Salesforce glue code
Ownership matters more than the route. Glue code fails quietly, as a sync that stopped last Tuesday or a field that maps to the wrong stage, and a customer usually finds it before your team does. Whoever owns it needs per-customer monitoring and the time to test each Salesforce release.
There are three realistic owners. Your own engineers own it when the integration is part of your product's core and you can staff it after launch, not just during the build. An embedded platform helps when you want your engineers to keep ownership on shared tooling. Appnigma's integration infrastructure is built for that case. Your engineers build the integration logic on Appnigma's infra, so the next customer's custom objects and field mappings fit without rebuilding the integration for everyone. A partner owns it when integrations are a sales requirement but not where you want engineering time to go. That is the done-for-you model, with a named engineer who builds and maintains each integration.
Shipping inside Salesforce adds packaging, security review and listing work on top. For that path, our post on what a native Salesforce integration is compares the package with an API connector in more detail.
Frequently Asked Questions
What is glue code in a Salesforce integration?
It is the custom code that connects your product to a customer's Salesforce org. It owns the OAuth connection and the field mapping for that org, plus the sync, retry and API version logic around them.
Does a managed package remove the need for glue code?
No. It moves the code into the customer's org and lets you push upgrades, but the API calls it makes still count against that org's daily limit.
Can you update an unmanaged package after customers install it?
No. Salesforce says the publisher "can't change or upgrade" installed components, so every fix becomes a manual edit in each customer org.
When does old Salesforce glue code stop working?
When its pinned API version retires. Versions 31.0 through 40.0 are unsupported from Summer '27 and retired from Summer '28, when calls return 410.
Can Appnigma build and maintain our Salesforce integrations?
Yes. Appnigma's done for you delivery builds and maintains customer integrations with a named integration engineer, and marketplace apps covers native Salesforce apps with 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 Is a Native Salesforce Integration
- What Is a Salesforce Native App
- Salesforce Integration Tools Compared
- Native Integration vs iPaaS for SaaS Teams
- Salesforce iPaaS or a Native App
Sources
- Salesforce Developers, Salesforce Developer Limits and Allocations, API Request Limits and Allocations
- Salesforce Developers, Salesforce Developer Limits and Allocations, Bulk API and Bulk API 2.0 Limits and Allocations
- Salesforce Developers, Change Data Capture Developer Guide, Select Objects for Change Notifications
- Salesforce Developers, Change Data Capture Developer Guide, Change Data Capture Allocations
- Salesforce Developers, REST API Developer Guide, API End-of-Life Policy
- Salesforce Developers, REST API Developer Guide, OAuth and Connected Apps
- Salesforce Developers, 2GP Developer Guide, Connected Apps and External Client Apps in 2GP
- Salesforce Developers, ISVforce Guide, Secure Your Connected Apps and ECAs
- Salesforce Developers, Named Credentials Developer Guide, Get Started
- Salesforce Developers, Named Credentials Developer Guide, Package Credentials
- Salesforce Developers, 1GP Developer Guide, Developing and Distributing Unmanaged Packages
- Salesforce Developers, AgentExchange Install Guide, Prepare to Install an AgentExchange Package
- Salesforce Developers, Apex Developer Guide, Managed Package Types
- Salesforce Developers, 1GP Developer Guide, Push Upgrades
- Salesforce Developers, 2GP Developer Guide, Enable a Package Subscriber to Restrict Push Upgrades
- Salesforce Developers, ISVforce Guide, Security Review Guidelines
- Salesforce Developers, ISVforce Guide, Test Your Entire Solution
- Salesforce Developers, Apex Developer Guide, Callout Limits and Limitations
- Salesforce Developers, Apex Developer Guide, Queueable Apex
- Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
