SAP's New API Policy: What It Actually Means for Your Salesforce Integration

In late April 2026, SAP published an update to a governance document almost no Salesforce architect had ever read: its API Policy. Six weeks later, on 9 June, a security patch started enforcing part of it - adding a check to a core SAP data-provisioning interface that silently rejects any caller SAP doesn't recognise as another SAP system. Pipelines that had run unremarked for years stopped working that week; one widely reported case involved a manufacturer's Microsoft Fabric pipeline pulling SAP S/4HANA finance data through Azure Data Factory's SAP connector, which lost that connection the day the patch shipped. If your Salesforce org talks to SAP, this is worth an actual audit, not a skim of the headline.

The short answer

In brief: if your Salesforce-SAP integration runs through middleware (MuleSoft, Boomi, Informatica, or similar) calling a published, documented SAP API - the pattern behind most everyday order, account, and invoice sync - it's likely unaffected so far, provided the API is actually listed on SAP's Business Accelerator Hub and the traffic is bounded operational volume rather than bulk extraction. For Salesforce architects specifically, the SAP API policy's Salesforce integration exposure splits into three narrower risk areas: integrations that read SAP data through ODP-RFC (common in BW/analytics extraction and older 'replicate everything' jobs), custom code that calls undocumented function modules or raw table reads as a workaround, and any Agentforce or other AI agent that plans and executes its own sequence of SAP calls rather than triggering one defined action - a distinction we flagged in a different context in Salesforce in Claude's access model: an AI system inherits a lot more reach than it looks like on paper, and SAP has now drawn its own line around exactly that pattern. None of this means panic-migrate everything. It means finding out, this quarter, which of those patterns your org is actually running - because for a lot of organisations, nobody currently knows.

What SAP actually changed

SAP's API Policy v4/2026, published on the SAP Help Portal in late April 2026, restates a principle SAP has pushed for years under its 'clean core' strategy: only officially released, documented interfaces - listed on the SAP Business Accelerator Hub or in product documentation - are sanctioned for customer or third-party use. What made this update different is that SAP backed it with a technical enforcement mechanism instead of leaving it as guidance. SAP Note 3255746, revised to version 11 on 21 April 2026, restricts the RFC-based calls of the Operational Data Provisioning API (ODP-RFC) to SAP-to-SAP traffic only. A security patch shipped on 9 June 2026 adds a subscriber-type check to every ODP call: if the calling system doesn't identify itself as SAP, the call is rejected. Separately, section 2.2.2 of the policy restricts "(semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls" against SAP outside SAP's own endorsed pathways - language written with agentic AI platforms in mind, with Agentforce and Microsoft Copilot both named in early industry analysis of the policy's scope.

1. Late April 2026

   SAP API Policy v4/2026 published

   Updated on the SAP Help Portal with limited advance notice to the wider ecosystem.

2. 21 April 2026

   SAP Note 3255746 reaches version 11

   Formally restricts ODP-RFC to SAP-to-SAP data transfer only.

3. 9 June 2026

   Enforcement patch ships

   A subscriber-type check blocks non-SAP callers on ODP-RFC; BW/analytics pipelines are hit first.

4. Through summer 2026

   Public pushback and clarification

   The German-speaking SAP user group DSAG and analyst firm Forrester both raise concerns about scope and clarity; SAP restates that documented integrations aren't the target.

Who should actually worry

SAP has been explicit that it isn't trying to break ordinary integrations: connections built on documented APIs for documented purposes aren't expected to fail, and the company has said enforcement favours monitoring and dialogue over outright blocking for now. That's a real gap between stated intent and what the ODP-RFC patch actually did to pipelines using that specific interface, and it's the reason this is worth checking rather than dismissing as a BW-team problem. If your organisation has no clear answer to whether its SAP integration was ever documented as using a published interface, that uncertainty is itself the finding a Salesforce Health Check's integration review is built to surface, alongside the rest of an org's technical debt.

What to do this quarter

1. Run SAP's self-assessment for ODP-RFC exposure (SAP Note 3439624), or ask whoever owns Basis to run it - it's the fastest way to find out whether June already broke something nobody's noticed, since a degraded SAP-side component doesn't always throw an obvious Salesforce-side error.
2. Inventory every integration that moves data between Salesforce and SAP, and classify each one against the four patterns above - from the actual connector configuration, not from memory.
3. Ask your middleware vendor, in writing, which of the SAP connectors you use call published interfaces versus undocumented ones. 'SAP-certified connector' describes the vendor relationship, not necessarily how your specific integration was configured to use it.
4. If Agentforce or another AI agent touches SAP data today or is on the roadmap, check whether the action is a single, defined call or something that plans its own sequence of SAP requests - that distinction is exactly what section 2.2.2 targets.
5. Assign explicit ownership of SAP integration compliance if nobody currently has it. This sits in the gap between a SAP Basis team and a Salesforce admin team by default, and a policy like this is exactly what falls through that gap.

What not to do yet

• Don't rip out a working Salesforce-SAP integration just because the phrase 'SAP API policy' is now circulating internally - most ordinary order, account, and invoice sync sits on the compliant side of this, and rebuilding something that already works is its own risk.
• Don't assume 'SAP-certified connector' automatically means your specific configuration is compliant - certification covers the vendor relationship, not how a particular customer implemented it.
• Don't treat this as settled. SAP's stated preference for monitoring over blocking, alongside DSAG's public comments that the policy's wording leaves customers uncertain about scope, both point to more clarification and likely more enforcement edges through the rest of 2026 - not fewer.

Why not just route everything through SAP's own layer?

SAP's cleanest path to compliance is, unsurprisingly, routing everything through SAP's own endorsed pathways - Integration Suite for data movement, Joule for agent-to-agent interaction. For organisations already committed to that stack, that's a reasonable call. But it's worth naming the trade-off before defaulting to it: it also means SAP mediates, and can reshape, every future Salesforce-SAP interaction, in a market where SAP has just shown it will change API access rules with roughly six weeks' notice. An architecture that satisfies the policy today by calling only published, documented interfaces through independent middleware stays compliant without adding that dependency - and for most organisations, rebuilding a handful of non-compliant integrations is materially less work than a platform migration justified by a policy document rather than a business requirement.

A few questions worth asking before your Basis team asks you

Does this ban MuleSoft or Boomi connections to SAP?

No. The policy restricts which SAP interfaces can be called and how, not which middleware product does the calling. A MuleSoft or Boomi integration that calls a published, documented SAP API - a standard Sales Order or Business Partner OData service, for example - is on the compliant side regardless of which platform sits in the middle. The risk is specific to the interface being called, most commonly ODP-RFC or an undocumented function module, not the choice of iPaaS.

Is Agentforce banned from touching SAP data?

Not outright. Section 2.2.2 targets AI systems that autonomously plan and execute their own sequence of SAP API calls, not every AI feature that happens to read SAP-sourced data. An Agentforce action that's been scoped and defined in Agentforce Studio to make one specific, bounded call is a different case from an agent reasoning its way through which SAP endpoints to hit next. The distinction is about who decides the sequence of calls - your architecture at design time, or the model at runtime.

What is ODP-RFC, and does our org actually use it?

Operational Data Provisioning via RFC is the interface SAP's own BW/BI extraction tooling has used for years to pull data out of SAP systems in bulk, and a number of third-party ETL and replication tools adopted it as a convenient way to read the same data. If your Salesforce integration was built as a point-to-point API call rather than a bulk data-replication job, it's less likely to touch ODP-RFC directly - but 'less likely' isn't the same as 'confirmed,' which is why SAP's own self-assessment tool (Note 3439624) is worth running rather than guessing.

Has SAP delayed enforcement?

Not as far as public reporting shows. The 9 June 2026 patch shipped on schedule, and coverage through the following months describes SAP continuing to enforce the ODP-RFC restriction rather than rolling it back. Treat any claim that enforcement has been paused as something to verify directly with SAP or your Basis team before relying on it - a policy this recent is exactly the kind of thing where third-party summaries can go stale fast.

The bottom line

SAP didn't ban Salesforce-SAP integration in 2026 - it drew a line around which interfaces count as supported, and enforced part of that line with a patch rather than a warning. For most everyday CRM-to-ERP sync built on published APIs, that line doesn't move much. For the older, undocumented, 'it's always worked' connections that accumulate in any Salesforce org running alongside SAP for more than a few years, this is the first time anyone's had a concrete reason to go find them. If the inventory above turns up a handful of integrations that need rebuilding on a published interface, that's bounded, well-scoped work - closer to a Fix Sprint than a platform migration. And if nobody in your organisation can currently answer which pattern your SAP integration actually uses, that's worth a second opinion before SAP's next policy update answers it for you.