New SAP API Policy: DSAG sees a need for clarification, specification and adoption

Specifically, SAP’s new policy stipulates that only those interfaces listed in the “SAP Business Accelerator Hub” or in the relevant product documentation are considered published APIs. “For SAP-to-non-SAP scenarios, this means that reliable support is only available where SAP has explicitly published and documented the underlying interfaces,” explains Jens Hungershausen, DSAG Chairman of the board. In DSAG’s view, the “SAP Business Accelerator Hub” and unspecified prod-uct documentation have not yet been clearly defined as contractual components. From the customer’s perspective, this creates a compelling need for clear and reliable framework conditions to enable the early assessment of the impact of changes. “DSAG has long been calling for absolutely reliable contractual documents. However, SAP is taking the opposite stance, for example, with the SAP Business Data Cloud and now also with the API Policy. Customers currently still have questions regarding the interpretation of the documents - from DSAG’s per-spective, there is a need for clarification regarding the contractual classification; this is unacceptable,” says Michael Bloch, Board Member Licensing, Contracts & Support.

Impact on existing integration and innovation scenarios is expected

In addition, SAP links API usage to clear technical and organizational requirements. Use for undocumented purposes, for systematic or largescale data extraction, and for use in conjunction with (semi-)autonomous or generative AI systems is also restricted, unless this takes place explicitly within architectures or services provided by SAP. “According to information available to DSAG, existing customer integrations and authorized partner solutions are not affected. This is essential from the customer and partner perspective,” says Stefan Nogly, DSAG Board member Technology, adding: “Protection for existing integrations tolerated by SAP is important and should be enshrined in the API Policy.”

The SAP adjustment comes against the backdrop of identified security risks asso-ciated with certain usage patterns, as well as a sharp overall increase in API usage. “In practice, interfaces that were not officially documented or approved have also been used in the past. Experience shows that undocumented interfaces are frequently used, particularly in add-on solutions from partners,” says Hungershausen.

Users are critical of potential commercialization

DSAG points out that any potential new pricing models or usage policies related to APIs must be communicated transparently and well in advance to ensure planning certainty for customers and partners. SAP has already developed a pricing model for the creation of certain document types in indirect use with the Digital Access Model. “According to SAP, there is supposed to be a fair-use model. The specific details are still unclear at this time and should be transparently documented in the API Policy,” Bloch demands.

Clarify impacts on innovation and AI projects early on

“From the customer’s perspective, we see a significant need for clarification and adaptation—especially to avoid disrupting existing business-critical end-to-end processes or making them legally vulnerable,” says Nogly. Many user companies are already working on proof-of-concepts and pilot projects based on the current interpretation of API usage.

According to DSAG’s understanding, the policy is initially intended to apply primarily to new customers and contracts and will not result in technical restrictions on existing integrations in the short term. However, it has not yet been definitively clarified how SAP plans to proceed with regard to the new policy when renewing or extending existing contracts. “The decisive factors are the long-term impacts on innovation capacity as well as potential new costs and dependency structures. In an era of increasingly heterogeneous architectures and intensive AI experiments, APIs are a key driver of innovation,” says Nogly. From DSAG’s perspective, the current announcements are causing uncertainty among customers and partners. From the user’s perspective, for example, this raises the question of whether such projects can even be operated productively and in compliance with guidelines in the future. Changes to API status, usage rights, or supported scenarios must not be made unilaterally or retroactively. This is the only way to avoid legal risks, service interruptions, and subsequent restrictions on existing integration and innovation scenarios, and to ensure the required planning certainty for customers.

Greater transparency, support, and realistic transition periods are needed

The lack of transparency is particularly critical: neither is it clearly documented which specific APIs are affected, nor is the scope clearly defined. “The question is which interfaces are used in the partner solutions,” says Hungershausen. According to DSAG’s understanding, those using official APIs do not need to take any action, although the lack of contractual safeguards means there is no absolute certainty. For some partner companies, however, the effort involved could be significant, and business models could be at risk of collapsing. “That is why it is essential that SAP grants customers more time for the transition,” demands Hungershausen. In addition, customers and partners need concrete technical and organizational support for the switch to SAP-supported interfaces. From DSAG’s perspective, it is crucial that customers do not have to switch to other solution providers due to a lack of viable alternatives when existing scenarios are restricted.

DSAG therefore calls for clear definitions, comprehensive documentation of the affected APIs, and reliable planning certainty for customers and partners, as well as provisions in the contracts that allow customers to make a sound assessment of use cases. The relevant provisions should be understandable and transparent. Furthermore, they must not lead to increased costs for customers and partners. “Against the backdrop of secure and stable operations, it is also important for us as users to have full transparency regarding usage, consumption, and consequences,” says Nogly.

From DSAG’s perspective, the current structure of the API Policy raises questions. The scope of the restrictions appears to go beyond what is technically necessary. To ensure long-term innovation and planning certainty for customers and partners, these open issues must be clarified as soon as possible through collaboration between SAP and DSAG.