DSAG criticizes new SAP API policy

SAP has specified its guidelines for handling interfaces in order to better secure the rapidly increasing use of APIs by non-SAP systems as well as new cloud and AI-based scenarios. The aim is to address potential risks to performance, stability and security at an early stage. While SAP justifies the new API policy with legitimate security interests and the guarantee of technical stability, the German-speaking SAP user group (DSAG) sees a considerable need for clarification, specification and adaptation.

No contractual protection

Specifically, SAP's new policy stipulates that only 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.

In the opinion of 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. «DSAG has been calling for absolutely reliable contract documents for some time. However, SAP is taking the opposite 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 & Support.

Effects on existing integration and innovation scenarios

In addition, SAP combines API use with clear technical and organizational requirements. Usage is restricted for undocumented purposes, for systematic or large-scale data extractions and for use in conjunction with (semi-)autonomous or generative AI systems, unless these take place explicitly in architectures or services provided by SAP.

«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 Chief Technology Officer, and adds: «Protection for existing integrations that are tolerated by SAP is important and should be included in the API policy.» 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 with additional solutions from partners.

Possible commercialization causes scepticism

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. «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.

AI projects and innovative capacity at stake

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 contract extensions or expansions.

«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. «The long-term effects on the ability to innovate 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.»

Changes to the API status, usage rights or supported scenarios should 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.

More transparency and realistic transition periods required

DSAG is particularly critical of the lack of transparency: it is not clearly documented which APIs are specifically affected, nor is the extent clearly defined. For some partner companies, the effort involved could be considerable and there is a risk of business models being lost. «It is therefore essential that SAP gives customers more time for the transition,» demands Hungershausen.

In addition, customers and partners need specific technical and organizational support for the changeover to SAP-supported interfaces. From DSAG's point of view, it is crucial that customers do not have to switch to other solution providers due to a lack of practicable alternatives if existing scenarios are restricted. DSAG is therefore calling for clear definitions, complete documentation of the affected APIs and reliable planning security for customers and partners, as well as mapping in the contracts. «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 point of view, the current design of the API policy raises fundamental questions. The scope of the restrictions appears to go beyond what is technically necessary. 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.

More information: www.dsag-ev.ch