What Customers Need to Know About SAP’s API Policy
Key Takeaways
⇨ SAP’s API Policy leaves most documented integrations and legitimate custom ABAP interfaces intact, while tightening controls around unsupported access patterns.
⇨ Third-party integration and AI platforms can still connect to SAP, but agentic AI must meet stronger governance requirements around access and execution.
⇨ SAP customers should review API inventories, unsupported interfaces and autonomous workflows before expanding AI agents across production ERP systems.
When SAP introduced its new API Policy in April, it established firmer boundaries around how customers, partners and automated systems can access SAP applications. Published APIs were tied to documented uses, non-published interfaces faced tighter restrictions, and SAP added specific controls for generative or semi-autonomous systems that can orchestrate sequences of API calls.
The change quickly raised questions about existing integrations, custom code, partner products and whether SAP’s published APIs exposed enough functionality to replace undocumented interfaces. SAP has since clarified many of those points. Existing documented integrations are not expected to be affected, customer-developed APIs remain permitted within defined limits, and third-party integration platforms can still connect to SAP. The bigger change concerns agentic AI, where systems that independently decide which SAP APIs to call now face stricter governance requirements.
Does SAP’s API Policy Affect Existing Integrations?
For most existing integrations, the immediate answer is no. SAP says integrations and extensions that use APIs for their documented purposes are not expected to be affected by the policy. Customers should still validate those connections against the relevant product documentation, including any applicable rate limits and security controls.
The position is more complicated for integrations built on undocumented interfaces. SAP says it will not retroactively invalidate those integrations simply as a policy enforcement action. In many cases, these interfaces can continue to operate, but without the same stability or support guarantees as published APIs. Interfaces that SAP has explicitly prohibited are treated separately.
Can Customers Still Use Custom ABAP and Custom APIs?
Yes. SAP says customer-developed interfaces remain permitted, including custom ABAP interfaces, OData services, CDS views and RFC modules built in the customer namespace. The policy does not treat this code in the same way as SAP’s own internal or private interfaces.
The restriction applies when custom code is used to bypass SAP’s API controls. SAP says customer-developed interfaces cannot create unreasonable load or security risks, access protected internal components, or become an alternative route for unendorsed agentic AI or mass data extraction.
Customers can therefore continue to maintain legitimate custom integration and extension logic, but they have greater responsibility for understanding what those interfaces connect to and how they are being used.
Are Third-Party Integration Platforms Still Allowed?
Yes. SAP says the policy applies regardless of whether an API is called through SAP Integration Suite, API Management, third-party middleware or custom integration tooling. The compliance question is the SAP interface being used and the access pattern, rather than the integration platform itself.
SAP Integration Suite is an endorsed pathway, but it is not mandatory. Third-party iPaaS and middleware platforms can remain compliant when they connect through published APIs and operate within SAP’s documented controls. Architectural changes are more likely where an integration depends on non-published APIs or falls under restrictions covering autonomous AI access or large-scale data extraction.
What Changes When an AI Agent Calls SAP APIs?
SAP says deterministic automation, including rule-based RPA that follows predefined API call sequences, does not fall under the specific restriction on agentic AI.
The restriction applies when an AI system can independently decide which SAP APIs to call and in what sequence. SAP says these agentic access patterns must align with endorsed architectures and governance requirements covering authentication, authorisation, rate limits and auditability.
SAP’s concern is that a single prompt could trigger large numbers of API calls, while an agent without sufficient business context could access data outside its intended scope or write incorrect information back into the system.
How Can Third-Party AI Agents Connect to SAP?
SAP says third-party AI agents can still connect to SAP, but autonomous access must use governed pathways. Its current endorsed options include MCP Gateway on SAP Integration Suite, SAP-provided MCP servers through Joule Studio and the Agent2Agent protocol for communication between external and SAP-managed agents.
These pathways are designed to put controls such as authentication, authorisation, rate limiting and audit logging between the agent and SAP APIs. SAP also says customers can use third-party or custom MCP servers, provided they comply with the API Policy and its underlying controls. However, SAP does not provide the same support or stability guarantees for those implementations.
The result is that customers can still choose the AI platform they want to use, but how that platform reaches SAP now matters much more.
What Is Still Unclear About SAP’s API Policy?
SAP has clarified the policy’s broad boundaries, but it does not provide a binding decision matrix for every integration or automation pattern. Its FAQ describes the AI Golden Path as directional guidance and directs customers to SAP when uncertainty remains.
Some SAP support materials raise questions about mixed cases, including platforms with optional AI features and downstream consumers that add AI after an API has been published.
Pricing also remains unsettled. SAP says the policy does not change current licence grants or entitlements, while noting that technical options and commercial models will evolve as agentic and large-scale data access develop. The German-speaking SAP User Group, DSAG, has called for clearer pricing, contractual treatment and planning certainty.
Enforcement and responsibility are less clearly defined in mixed architectures. SAP’s support material raises questions about where conventional integration ends and agentic AI begins, as well as what responsibility falls on an API publisher when AI is introduced downstream. Customers may still need case-specific guidance where existing integrations, third-party platforms and AI overlap.
What Should SAP Customers Review Now?
The immediate task is to map the current integration estate against the policy. SAP recommends maintaining an inventory of custom APIs that records the namespace, interface type, purpose, owning team and underlying SAP dependencies.
Customers should confirm whether each connection uses a published interface for its documented purpose and identify any reliance on non-published or explicitly prohibited APIs.
AI and automation deserve a separate review. Teams need to identify where workflows remain deterministic and where an AI system is deciding which SAP APIs to call and in what sequence. Those agentic patterns may require different governance around identity, authorisation, rate limits and auditability.
Responsibility also needs to be clear before remediation work begins. SAP says customer-built integrations that rely on non-published APIs are not automatically covered by the standard RISE scope. Customers may therefore need to address ownership, timing and commercial terms separately with SAP or their implementation partners.
What This Means for ERP Insiders
Architecture choices now carry compliance consequences. Customers cannot judge policy exposure by vendor or platform alone. The same tool may be acceptable in one configuration and problematic in another. Architecture review therefore becomes part of compliance planning.
API inventories become prerequisites for agent deployment. Customers that already understand their published, custom and unsupported interfaces can assess agent access earlier. This reduces the risk of discovering integration constraints only after AI pilots are underway.
Agent governance moves into existing controls. AI projects will increasingly require involvement from identity, security, integration and authorisation teams before production deployment. Customers can treat agent access as an extension of established governance rather than a separate AI exercise.