SAP API Policy: Need for clarification

The new policy stipulates that only those interfaces that are identified in the „SAP Business Accelerator Hub“ or in the respective product documentation are considered published APIs. „For SAP-to-non-SAP scenarios, this means that they will only be reliably supported where SAP has explicitly published and documented the underlying interfaces,“ explains Jens Hungershausen, DSAG Chairman of the Board. According to DSAG, the „SAP Business Accelerator Hub“ and undefined product documentation have not yet been clearly defined as contract components. From the customer's point of view, this results in an urgent requirement for clear and reliable framework conditions in order to be able to assess the effects of changes at an early stage.

Demand: Resilient contracts

„DSAG has been calling for absolutely reliable contract documents for some time. However, SAP is taking a contrary position, for example with the SAP Business Data Cloud and now also with the API Policy. Customers still have questions regarding the interpretation of the documents - from DSAG's point of view, there is a need for clarification regarding the contractual classification, which is unacceptable,“ says Michael Bloch, DSAG Board Member for Licenses, Contracts and Support.

In addition, SAP combines API use with clear technical and organizational requirements. Restrictions are also placed on use for undocumented purposes, for systematic or large-scale data extraction and for use in conjunction with (semi-)autonomous or generative AI systems, unless these expressly take place in architectures or services provided by SAP.

Protection of existing integrations

„According to the information available to DSAG, existing customer integrations and authorized partner solutions are not affected. This is essential from a customer and partner perspective,“ says Stefan Nogly, DSAG Board Member for Technology, and adds: „Protection for existing integrations that are tolerated by SAP is important and should be included in the API policy.“ The SAP adjustment takes place against the backdrop of identified security risks in certain usage patterns and a strong overall increase in the use of APIs. „In practice, interfaces that were not officially documented or approved were also used in the past. Experience has shown that undocumented interfaces are often used, especially for additional solutions from partners,“ says Hungershausen.

Criticism of commercialization

DSAG points out that potential new pricing models or usage regulations relating to APIs must be communicated transparently and at an early stage in order to ensure planning security for customers and partners. With the Digital Access Model, SAP has already developed a pricing model for the creation of certain document types for indirect use. „According to SAP information, there will be a fair use model. The specific structure is currently still unclear and should be documented transparently in the API policy,“ demands Bloch.

„From a customer perspective, we see a considerable need for clarification and adaptation - especially in order to avoid interrupting 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 previous interpretation of API usage. DSAG understands that the policy should initially be relevant primarily for new customers and contracts and should not lead to technical restrictions on existing integrations in the short term. However, it has not yet been conclusively clarified how SAP plans to proceed with regard to the new policy for contract extensions or expansions of existing contracts. „The long-term effects on innovation capability and possible new cost and dependency structures are crucial. In a phase of increasingly heterogeneous architectures and intensive AI experiments, APIs are a key innovation factor,“ says Nogly.

More transparency required

From DSAG's perspective, the current announcements are causing uncertainty among customers and partners. From the user's perspective, for example, the question arises as to whether such projects can later be operated productively and in compliance with guidelines at all.

Changes to the API status, usage rights or supported scenarios must not be made unilaterally or retroactively. This is the only way to avoid legal risks, business interruptions and subsequent restrictions to existing integration and innovation scenarios and to guarantee the required planning security for customers. The lack of transparency is particularly critical: it is not clearly documented which APIs are specifically affected, nor is the extent clearly defined. „The question is which interfaces are used in the partner solutions,“ says Hungershausen. According to the SAP User Association, those who use official APIs do not have to do anything, although the lack of contractual security means that there is no absolute certainty.

Business models under threat

For some partner companies, however, the effort involved could be great and there is a risk that business models could be lost. „It is therefore essential that SAP gives customers more time for the transition,“ demands Hungershausen. In addition, customers and partners also need specific technical and organizational support for the changeover to SAP-supported interfaces. From DSAG's point of view, the current design of the API policy raises questions. The scope of the restrictions appears to go beyond the necessary technical level.

In order to ensure innovation capability and planning security for customers and partners in the long term, these open points must be clarified as quickly as possible in cooperation between SAP and DSAG.

(Source: DSAG)