Salesforce started charging for the seam between your org and everything else. That is an architecture problem, not a procurement one.
There is a sentence from Tyler Carlson, Salesforce’s SVP and head of product for AppExchange and ecosystem, that explains more about the next five years of Salesforce architecture than any keynote has:
“When you use our API, you are using Salesforce compute.”
That is not a complaint about anything. It is defensible. Compute costs money, and a company that has spent twenty years absorbing the cost of everyone else’s integration traffic is allowed to notice.
But it changes something, and most orgs have not caught up to what. The boundary between your Salesforce org and every other system you own used to be a technical decision. It is now a commercial one, and traffic across it is billable. Architectures that were merely inelegant in 2023 are line items in 2026.
This is what changed, why it got bigger this year, and what to do about it before the invoice explains it for you.
What actually changed
In February 2025, Salesforce revised the legal terms governing how third-party applications access Salesforce data. Quiet change. Developer-blog post about MSA revisions. The kind of thing that gets skimmed and filed.
The AppExchange Partner Program governs how third-party vendors build and distribute commercial applications that touch Salesforce data. Any partner building a commercially distributed application has to enroll, whether that application authenticates Salesforce users, synchronizes data, or operates at scale via APIs.
Enrolled partners land in one of two commercial models:
API-based integration vendors (data pipeline and connector providers) join the Connector program and pay a base fee that scales with usage and volume.
Vendors building directly on the Salesforce platform are subject to revenue sharing instead.
Two models. Two very different cost curves. Hold onto that, because it is the whole argument.
Earlier in 2025, Salesforce raised the Connector program base fee for the first time since the program launched in 2016. Fees are structured as a flat charge per user or environment, scaled by usage and volume, but actual rates are negotiated individually with each partner under what a Salesforce spokesperson called a “fair value exchange.”
Read that again. The rate is not published. It is negotiated privately, partner by partner.
Fivetran was among the first to say out loud what that does to a data-integration business. CEO George Fraser laid out the options: absorb the cost, pass it to customers and risk backlash, or find alternative access paths and risk the Salesforce relationship. His larger concern was about what it does to customer optionality. Customers might no longer be able to use Fivetran to replicate data to Snowflake and would use Data Cloud instead. They might not be able to interact with their data via ChatGPT and would use Agentforce instead.
Salesforce’s position is that this is ordinary industry practice, and that charging for API access reflects the real cost of operating, securing, and supporting enterprise infrastructure at scale.
Both of those things are true at once. Compute is not free. And a price applied at the integration boundary shapes which architectures live and which quietly become too expensive to keep.
Then it got a lot bigger
If this had stopped at connector fees, it would be a vendor-margin story that consultants could safely ignore. It did not stop.
In April, Salesforce launched Headless 360. On the Q1 FY27 earnings call, executives framed it as both an AI-era architecture shift and a fresh monetization opportunity, as enterprises increasingly reach Salesforce data through APIs and MCP servers, meaning AI agents, Slack bots, and external copilots, instead of through the traditional application UI.
Chief Revenue Officer Miguel Milano was direct about the commercial half. The plan is to bring agentic CRM to every surface, and to work with customers and partners to find the right ways to monetize those new interactions and those new users accessing the platform.
New users. That is the reframe worth sitting with. An AI agent hitting your org through an MCP server is, commercially, a user. It does not sleep, does not take PTO, and has no natural ceiling on how many records it touches per hour.
Dion Hinchcliffe of The Futurum Group put the risk precisely: the problem is not the unit price of an API call, it is the multiplication effect. Autonomous agents generate tens of thousands of CRM interactions continuously across sales, service, marketing, analytics, orchestration, and external AI systems. His read on the outcome is that CIOs lose the budget predictability they have always associated with CRM and trade fixed SaaS spend for cloud-style elastic consumption economics.
Scott Bickley of Info-Tech Research Group adds a volatility layer: API- and token-driven consumption fluctuates with model routing, context caching, prompt efficiency, and shifting AI model prices. His summary of the direction of travel is not subtle. Automation based on consumption metrics increases transaction volumes, and as the underlying modules of Salesforce get called for an integrated experience, each with its own billable layer, costs explode higher.
Two more data points, and then the picture is complete.
Salesforce declined to comment on how API and MCP interactions under Headless 360 are currently billed. Analysts believe most calls are currently billed through a mix of existing API consumption, Agentforce usage constructs, platform entitlements, and negotiated enterprise agreements rather than a single clean per-call price.
And in June, Salesforce moved to acquire m3ter, a usage-based billing specialist.
Nobody buys a metering company to keep selling seats.
Say “lock-in” precisely or do not say it
The word gets thrown around until it means nothing. Sanchit Vir Gogia of Greyhound Research has the version worth using:
“This is not traditional technical lock in where migration is impossible. It is behavioral lock in created by layered dependency over time. When integrations, data movement, and AI permissions all flow through a single commercial framework, alternatives become theoretically viable but practically disruptive.”
Nobody is trapped. Every alternative is still technically available. It is just that after four years of individually reasonable integration decisions, using those alternatives means unwinding work that six teams depend on and nobody has budget to redo.
That is the part that makes it an architecture problem. The cost of the dependency arrives years after the decisions that created it, which means it has to be evaluated at design time by someone whose job is to think in five-year horizons. Procurement cannot catch this. Procurement sees the invoice.
The downstream math is already visible. Pareekh Jain of Pareekh Consulting notes that higher Connector base fees increase the cost of integrations, AI extensions, and niche apps, and that ISVs forced to pay will either absorb it or raise subscription prices to hold margin. Gaurav Dewan of Avasant puts a number on the customer side: double-digit percentage increases in Salesforce-related spend if ISVs pass the cost through.
Dewan also names the part that makes forecasting impossible. Case-by-case negotiation creates uncertainty and risk for the CIOs relying on the affected products. When your vendor’s cost basis is set in a private negotiation you are not party to, you cannot model your own three-year TCO. You can only wait to be told.
There is a counterweight, and honesty requires including it. Ashish Chaturvedi of HFS Research argues that metering every MCP call creates a perverse incentive: customers throttle agent usage to control costs, which kills the adoption flywheel Salesforce needs to justify the strategy. Salesforce is caught between monetizing a new surface and taxing the behavior it is trying to encourage.
That tension is real, and it may eventually bend the pricing back. It is not something to bet an integration architecture on.
Native or nothing, now with a business case
Here is where this stops being industry news and starts being a design constraint.
For most of the last decade, native versus integrated was a technical argument. Build on-platform when you need transactional consistency with CRM data, sharing-model enforcement, or a UI inside Lightning. Integrate when you need compute the platform cannot give you, libraries that do not exist in Apex, or a system of record that genuinely lives somewhere else. Cost entered the conversation as build cost. Run cost was somebody else’s problem, mostly because run cost was close to zero.
That era is over. Go back to the two commercial models.
A usage-scaled fee grows with your success and is not under your control. Data volume grows. Agent traffic grows. Sync frequency creeps up because somebody wanted fresher dashboards. Every one of those is a cost increase you did not approve, at a rate you did not set, discovered in arrears.
A revenue-share arrangement grows with revenue. Larger in absolute terms for a successful product, and not free. But proportional to something you can forecast, and the ratio holds whether your agents make a thousand calls a day or a million.
For an architect, the design question has a new second half. Not just where does this logic belong, but which side of the metering boundary does this traffic land on, and who sets the rate.
Four things that changes in practice.
API-chatty integrations became liability line items. The polling job that syncs every fifteen minutes because fifteen was the default. The middleware that re-reads reference data on every transaction. The connector pulling full objects when it needs four fields. All of that was always sloppy, and it was always tolerable, because the marginal cost of an API call rounded to nothing. It does not round to nothing anymore, and the multiplication effect turns yesterday’s laziness into this quarter’s variance.
Logic that could live on-platform probably should. If a piece of business logic takes three round-trips to external middleware, and the same logic could run in Apex against records already in memory, those round-trips are now recurring cost rather than stylistic preference. Apex, Flow, and Platform Events do not cross the metering boundary. This is the strongest argument for on-platform implementation in years, and the funny part is that it came from finance rather than engineering.
Data residency decisions carry weight they did not carry before. Every architecture treating Salesforce as source and something else as analytical destination now has a per-unit cost on the pipe between them. That does not automatically make Data Cloud the right answer. It means the comparison has to include the metered cost of the alternative across the actual life of the system instead of the first year of it.
Agent architecture needs a cost model before it needs a demo. Bickley’s buyer questions are the right ones to ask at design time: What counts as a billable call? Are internal agent calls priced differently from customer-facing ones? Are there caps or alerts? Can consumption spike unexpectedly? Ask during design. Asking after a successful pilot, when someone wants to scale it to production, is asking too late.
And underneath all four, an operational discipline that most orgs do not have yet. Hinchcliffe expects CIOs to need FinOps-style governance for CRM itself: token budgets, API quotas, policy-based throttling, workload prioritization, cost anomaly detection, business-unit chargeback. If nobody in your org can name which integration generates the most API traffic this month, that is a governance gap with a due date on it.
Ninety days, in order
Inventory every connected app and integration, with traffic attribution. Not a list of names. A list with API call volume per integration per month. Dewan’s advice is to map all third-party apps and estimate new commission and licensing costs in advance. You cannot negotiate or optimize what you have not measured, and most orgs have not measured this since the last governor-limit scare.
Retire what is not earning its traffic. Dewan also recommends retiring underused integrations and consolidating functionality to reduce dependency on high-fee apps. Every org has a connector installed for a 2023 pilot that still runs a nightly sync nobody reads. That used to be untidy. Now it has a price.
Get contractual protection at renewal. Phil Fersht of HFS Research advises using renewal windows to secure caps on fee increases and to explore tiered pricing rather than absorbing pass-through cost. Adam Mansfield of UpperEdge frames it as negotiating the right pricing and volume discount structures along with transparency, flexibility, and protections for consumption pricing. He also names the vendor’s own model for it: “They refer to this as the ‘flywheel effect’. Once usage starts to spin, it keeps spinning more and the fees keep coming in and their revenue accelerates with it.”
The flywheel is not a secret. It is on the earnings call. Plan against it.
Re-score the native-versus-integrated calls on your roadmap. Take the integrations planned for the next eighteen months and re-run them with metered API traffic as a five-year line item. Some stay right. Some flip. The ones that flip are the ones worth catching before they are built rather than after.
Hold pilots until the commercial model is legible. Bickley’s position is that CIOs should be hesitant to commit until the commercial model is formalized, communicated, and well understood, and that higher costs should tie to measurable productivity or revenue gains before automated workflows scale. Rebecca Wettemann of Valoir identifies predictability as one of the biggest hurdles CIOs face moving agentic workloads from pilot to production. Enthusiasm does not clear that hurdle.
The honest version
Salesforce is charging for something it used to include. The justification holds up: API access consumes real compute. The problem is not the existence of the fee.
The problem is that the rate is negotiated privately, the billing model is currently a blend of API consumption, Agentforce usage constructs, platform entitlements, and negotiated agreements rather than a published price, and the volume driver is autonomous software that scales faster than any budget cycle.
Chaturvedi’s summary of the cumulative effect is the one to keep: layering consumption metering on top of per-seat pricing on top of flex credits on top of ELAs produces a commercial model that requires a spreadsheet to decode and a lawyer to negotiate, and every layer of complexity hands a CFO another reason to slow down.
The translation for architects is short. Put logic where the data already lives. Move less of it. Know your call volume before somebody else tells you what it costs.
Native was the right answer more often than the ecosystem was willing to admit, back when the argument was purely aesthetic. Now it has a number attached.
Resource Interactive builds native Salesforce applications and consults on Marketing Cloud, Data Cloud, and platform architecture. Every app in the portfolio is 100% native. No middleware, no external escape hatches, nothing that turns into a support ticket in eighteen months. That was a design principle before it was a cost strategy. If you are re-scoring an integration roadmap against these changes, that is a conversation worth having.