SAP’s New API Policy Redefines Access in the AI Era—and Raises Concerns for Developers and Partners

SAP updated its API policy in April 2026, triggering debate among developers, partners, and customers. The update restricts system access to published, documented APIs and tightens how data can be accessed at scale, including by AI-driven tools.

SAP presents the change as a safeguard for performance, security, and system integrity. Developers and partners see different issues.

The policy raises practical questions about whether SAP’s APIs can support existing integrations and AI applications in SAP environments. It also raises questions about what that means for partner products built on those integrations.

The Policy Sets a Boundary Around Published APIs

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.

SAP Says Data Access Remains Open, but Use Is Controlled

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.

Widely Used Undocumented APIs Now Carry More 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.”

Developers and Partners Now Face a Decision

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.

What This Means for SAPinsiders

• Existing integrations face support risk. Integrations built on undocumented APIs may continue to function but now sit outside defined support boundaries. That shifts the risk from immediate failure to long-term instability, where changes can break functionality without warning or vendor accountability.
• API access becomes dependent on SAP. API access now depends on what SAP publishes and supports, rather than what systems can technically reach. That shifts control of integration and AI capabilities toward SAP’s API roadmap and release cadence. Businesses will need to plan integration and AI initiatives with SAP’s API availability in mind.
• Refactoring becomes a near-term priority. Refactoring is no longer only a future consideration for many environments. Organizations will need to inventory existing integrations, identify dependencies on undocumented APIs, and plan remediation before those patterns create operational risk.