SAPContractChange

SAP API Policy v4/2026: impatti

Why two pages of policy can redraw the boundaries of enterprise AI*

At the end of April 2026, SAP published, with relative discretion on the Help Portal, a two-page document destined to cause discussion: the SAP API Policy v4/2026a. Three sections, dry legal language, potentially huge impact on anyone who has ever integrated a non-SAP system or is building AI scenarios on ERP data.

La motivazione dichiarata è la tutela di “solution health and security” di fronte all’esplosione delle chiamate API da sistemi esterni, comprese le architetture AI. Motivazione legittima. Ma il testo della policy, a parere di molti, va molto oltre la gestione del traffico e questo è il punto che ha generato reazioni a catena tra clienti, partner, analisti e studi legali internazionali. 

SAP manages the data that feeds 90% of global supply chains. When it redefines the rules of access to that data, it is not a matter of updating the user manual: it is a matter of redrawing the boundaries of an ecosystem worth billions. 

 

What exactly does the policy say? 

The official text is available on the SAP Help Portal. I advise everyone interested to read it without intermediaries. For convenience and context, below I summarize and quote some parts of it.  

Section 1 introduces a clear classification into three categories: 

  • Published APIs: those documented in the SAP Business Accelerator Hub or in the specific product documentation. They are the only ones allowed for the intended use ("Documented Use"), which includes integration, extensions, data synchronization, data exchange, event triggers, and similar business scenarios.
  • Non-Published APIs: Section 1.2 is explicit: "Customer and third-party applications must not access, invoke, or interact in any manner with APIs that are not Published APIs." Limited exceptions: custom-developed ABAP APIs in private cloud and on-premise environments, if expressly authorized by SAP documentation. Everything else (including internal, private APIs, or those linked to confidential SAP clients like S/4HANA namespaces) is out of scope. And the policy warns: these interfaces can be modified or removed without prior notice.
  • Explicitly prohibited APIs: those classified as "Confidential and Proprietary" or blocked by specific SAP Notes. Emblematic case cited by analysts: ODP-RFC for third-party tools.

The critical point for many organizations is that RFC calls, BAPIs, and other traditional routes, for decades the backbone of SAP data flows, presumably fall into the category of non-published APIs. But let's move on to section 2 where we talk about controls. 

  • Specific API Controls (2.1) are the technical controls documented for each API: rate limits, quotas, deprecation schedules, limits for bulk extraction, security requirements. Nothing particularly new, but now formalized in a binding way. Good to know, but nothing more.
  • General API Controls (2.2) are "the problem". Section 2.2.1 prohibits the use of APIs for: competitive analysis, functions not provided for by the Documented Use (unless authorized by SAP), and any activity that creates risks for system performance, stability, or security.

Section 2.2.2 is the heart of the controversy. 

It reads verbatim: 

Except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes, SAP prohibits API use for: (a) interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls, and (b) scraping, harvesting, or systematic and/or large-scale data extraction or replication. 

Simplified: if your AI agent queries SAP autonomously (planning, selecting, or executing sequences of API calls) you are violating the policy, unless you go through architectures expressly approved by SAP such as Joule (SAP's AI), BTP, and SAP Business AI Platform. 

SAP reserves the right to monitor API use and to adopt "reasonable enforcement actions" in case of non-compliance. The provided measures are: throttling, suspension, or termination of access. And it is explicitly prohibited to bypass controls through "intermediary services, custom code or developments, proxies, gateways, impersonation techniques, or similar mechanisms."

The only explicitly guaranteed protection is towards legal obligations: the policy does not limit SAP's obligations related to data export or data egress required by specific regulations ( data portability, switching, legal retention). 

Le reazioni 

For a few months now, many have expressed their views. 

The Deutschsprachige SAP-Anwendergruppe (DSAG) published an official note on April 29, 2026, harsh in tone and precise in content, identifying three specific requests: clear definitions and complete documentation of the APIs involved, explicit contractual guarantees, and realistic transition times for those who depend on undocumented APIs.

Forrester summarized the picture in no uncertain terms: "Three weeks ago, the SAP API Policy v.4.2026a looked like a legal document with no enforcement infrastructure. After Sapphire 2026, it looks like a strategy with a product line attached.". Technical enforcement begins on June 9, 2026, with a security patch that blocks ODP via non-compliant RFC calls.

 

The contractual knot: is the policy really binding? 

The answer is "it depends". 

  • For cloud contracts (RISE, S/4HANA Cloud, BTP): an SAP Cloud Service Agreement is composed of Order Form, Supplemental Terms and Conditions, Support Schedule, SLA, DPA, and General Terms and Conditions. If the GTCs provide that SAP can update the Documentation unilaterally (as happens in many modern cloud contracts) the policy could already be contractually operational. For new contracts and renewals, it is almost certainly so.
  • For on-premise / perpetual license contracts: the structure is different (Order Form + Software Use Rights + GTC for Software and Support). The link with the Documentation published on the Help Portal is less direct and more contestable. Here, customers could have solid contractual arguments.
  • Per RISE with SAP / Private Cloud: la policy è esplicitamente applicabile. Il contratto RISE incorpora Supplemental Terms che richiamano la Documentation. 

Note: the above is my interpretation based on the many contracts viewed in my work. However, I advise a legal opinion on the subject, especially in "gray" cases. *Article signed by Jary Busato, SAM/ITAM Consultant at WEGG - The Impact Factory ATTENTION! This article is drafted by Jary Busato for informational and sharing purposes. The analyses and comments expressed represent the author's point of view and do not constitute legal advice or contractual consultation. The contents are based on publicly available sources cited at the end of the article. SAP SE and the mentioned products are registered trademarks of their respective owners. The author has no commercial affiliations with SAP SE nor with the cited vendors. The contents are updated to June 2026.

 

Sources and/or interesting articles on the subject 

  • SAP API Policy v4/2026a - official text (SAP Help Portal, April 2026) 
  • DSAG Pressemitteilung, 29 aprile 2026 
  • CIO.com — “SAP’s new API policy restricts AI access, draws customer criticism”, Manfred Bremmer, 4 maggio 2026 
  • SAPinsider — “SAP’s New API Policy Redefines Access in the AI Era”, Adam Pitman, 28 aprile 2026 
  • The Register — “AI clause in new SAP API policy provokes lock-in concern”, 29 aprile 2026 
  • Hunton Andrews Kurth LLP — “SAP’s New API Policy Raises New Compliance and Continuity Risks”, 26 maggio 2026 
  • Forrester — “SAP Is Attempting To Become The Gatekeeper Of Enterprise AI — CIOs Should Push Back”, maggio 2026 
  • Forrester — “SAP Sapphire 2026: The Autonomous Enterprise Is Credible, But It Comes With Concentration Risk”, maggio 2026 
  • diginomica — “SAP Sapphire 2026 — SAP CTO Philipp Herzig on SAP’s API policy changes”, giugno 2026 
  • Simplifier AG — “SAP API Policy: Facts, risks and recommendations for your AI strategy”, 2026 
  • AI Magazine — “Can AI agents still access SAP data under new API rules?”, 2026 
  • cio.inc — “Explained: Why SAP Rewrote Its Third-Party API Policy”, 2026 
  • blog.zeis.de — “A Clearer View of Your SAP Integrations Under the New API Policy”, giugno 2026 
  • SAP Community — thread “Impacts of SAP API Policy v4/2026 on existing customer integrations”, 2026 

Insights

Chi è coinvolto e in che misura 

La policy si applica a tutte le soluzioni SAP cloud e on-premise, inclusi S/4HANA Private Cloud (RISE) e tutte le line-of-business solution. 

  • Clienti con integrazioni legacy: chiunque abbia costruito connessioni negli anni scorsi su API non documentate (RFC, BAPI, route non standard) si trova tecnicamente fuori perimetro. La SAP Community ha già registrato numerose domande su architetture esistenti: CDS OData service custom, estensioni BTP, scenari di estrazione dati. La risposta di SAP è che le integrazioni esistenti non sono immediatamente colpite, ma la situazione cambia al rinnovo contrattuale. 
  • Partner e ISV: l’impatto è potenzialmente più severo. Molti add-on dipendono da API non standard per accedere a dati che le interfacce pubblicate non espongono. Migrare a Published API può richiedere riscritture significative o comportare perdita di funzionalità se le API equivalenti non esistono. 
  • Aziende con strategie di AI agentica: questo è il fronte più caldo. Strumenti come Agentforce (Salesforce), Copilot (Microsoft), ServiceNow, Workday Illuminate, Celonis… ovvero tutti sistemi che per loro natura “pianificano, selezionano ed eseguono sequenze di API calls”, se non instradati attraverso percorsi SAP-endorsed, sembrerebbero rientrare nella casistica della Sezione 2.2.2. 
02-s pattern02

Vorresti approfondire il tema dell’accesso indiretto in SAP?

CONTACT US TO LEARN MORE!