SAP’s updated API policy is turning a technical integration issue into a broader ERP architecture concern. The policy limits access to published APIs, restricts unsupported interface use, and places new boundaries around large-scale data extraction and AI systems that sequence API calls outside SAP-endorsed pathways.
The change raises practical questions for CIOs, architects, ERP program leaders, and technology partners. Existing integrations may depend on interfaces that are not formally documented, while emerging AI applications increasingly need controlled access to enterprise data and transactional workflows. A policy shift around supported API use can affect integration roadmaps, data replication strategies, partner products, and AI tools.
ERP teams now face a practical architecture question: which SAP access paths can support integration, reporting, partner products, and AI workflows without creating support or compliance exposure. APIs define how external applications connect to workflows.
SAP Draws a Line Around Supported API Use
SAP’s API policy centers on a simple distinction: published APIs are permitted, and non-published APIs are not. Published APIs are those listed in the SAP Business Accelerator Hub or identified in product documentation, and are intended for defined use cases such as integration, extension, and data exchange. Everything else falls outside that boundary.
The policy requires customers and partners to verify that each endpoint they use is a published API and to follow its documented purpose.
It also establishes a control model for how APIs can be used. SAP defines rate limits, quotas, and data transfer thresholds, and can monitor usage and enforce compliance through throttling, suspension, or termination of access.
The policy limits large-scale data extraction and replication outside SAP-defined pathways and constrains automated use, including AI tools that generate or sequence API calls.
An added exception allows some flexibility for the use of non-published APIs—such as custom-developed ABAP interfaces in certain environments—but leaves interpretation dependent on SAP documentation and authorization.
Analysis
What This Means for ERP Insiders
Supportability becomes the real API test. ERP teams must treat each connection as an architectural dependency, not just a working endpoint.
SAP Separates Data Ownership From Access Control
Speaking on SAP’s most recent earnings call, CEO Christian Klein said, “Customer’s data is customer’s data, and accessing those data, we are not going to charge,” emphasizing that the policy is not intended to restrict data access itself.
The boundary, in SAP’s view, sits at the layer above the data. “There is a big difference… about just accessing the data… versus accessing the IP, the domain knowhow sitting in our ERP,” Klein said, pointing to the semantic data model, process logic, and other structures that define how SAP systems operate. “We are going to protect that.”
This distinction shapes how SAP approaches API usage. Access to data remains open in principle, but interaction with that data is mediated through SAP-controlled interfaces. “We will provide those APIs, absolutely, clearly,” Klein said, framing access as something delivered through APIs that SAP defines and governs.
Klein also tied that control to system behavior at scale. “When there is mass data requests or millions of calls coming towards an API, we need to start throttling those APIs,” he said, describing it as necessary to prevent performance issues.
That framing has become central to the policy debate. SAP is drawing a line between customer data ownership and the technical pathways used to access that data. The question is which SAP-approved APIs, data services, and integration patterns customers and partners can use at scale.
Critics and user-group coverage have argued that this could give SAP more practical control over ERP data movement, especially as third-party AI tools begin to plan, select, and execute API calls. SAP has framed the policy as a clarification of supported API use, system stability, security, and data protection.
Analysis
What This Means for ERP Insiders
Data access becomes an architecture question. Ownership may remain with customers, but control now sits in the pathways that make SAP data usable.
Undocumented API Use Becomes a Support Risk
Robert Holland, who leads SAPinsider’s research practice, describes the policy as a response to behavior that is already widespread. “This seems to be more SAP trying to close the gate on the horse that’s already bolted,” he said, pointing to the widespread use of undocumented APIs across customer and partner environments.
Those APIs are often known and used because they return specific data or enable functionality that published interfaces do not expose. “Customers become unhappy when the functionality of one of those APIs changes,” Holland said, either because SAP fixes a problem, or because the interface was never tested against a new release.
Holland described SAP’s language as intended to make customers and partners reconsider using undocumented APIs. At the same time, he said the principle is not new and pointed to SAP’s clean core extensibility model, which pushes customers toward stable, supported interfaces.
The impact may be sharper for partners. Many add-ons depend on non-standard APIs to access data, and moving to published interfaces can require rewrites, or result in reduced functionality if equivalent APIs do not exist. Holland said, “Users are going to use the functionality that provides the results they need, but they now need to be clearer on the possible impact if that functionality is undocumented.”
Analysis
What This Means for ERP Insiders
Hidden dependencies become harder to defend. Undocumented APIs may still work, but their value now carries a clearer support and upgrade cost.
Partner Integrations Need a Support Check
Partners now need to assess whether working integrations remain supportable if they depend on undocumented APIs, large-scale extraction, or access patterns SAP does not endorse. The open question is what happens to existing integrations that rely on undocumented or non-published APIs. Many depend on interfaces that are accessible but not formally published, and now sit outside defined support expectations.
API use now depends on interfaces that SAP publishes, governs, and controls, creating a dependency on its API surface and how quickly it evolves. Where published APIs do not expose the same data or functionality, teams face a trade-off between maintaining existing behavior and moving to supported patterns.
The impact extends beyond integration design for partners. Products built on non-standard APIs may require redesign or deliver less functionality if equivalent interfaces are not available. That places pressure on roadmaps and customer commitments, especially where capabilities depend on access that is no longer supported.
Practitioners are already treating the policy as a signal to act. Jehangir Khan, a data, analytics, and AI expert at SAPinsider, said the update “reinforces a shift toward clean-core and controlled extensibility by limiting integrations to officially published APIs,” while requiring organizations to refactor integrations built on private or undocumented APIs.
He added that organizations should “accelerate API compliance, review integration strategies, and plan for potential rework in existing landscapes,” reflecting the expectation that existing implementations will need to change rather than be preserved.
Analysis
What This Means for ERP Insiders
Working integrations now need proof of support. Partner products must show that their SAP access patterns can survive policy enforcement, upgrades, and customer scrutiny.
About Us
ERP Today covers how ERP, cloud, and AI change the way businesses run. Our editors speak with practitioners, vendors, and analysts to surface the technology, contracts, and risks that matter for enterprise leaders.
Alongside our newsroom coverage, we run in‑person summits where ERP leaders compare notes on programs like yours, and a research practice that turns reporting like this into organization‑specific briefings and content.
SAPinsider first published a version of this article on April 28, 2026.
