Last Updated on May 18, 2021 by

Executive Summary

  • SAP proposes greatly enhanced integration with REST/JSON APIs.
  • We question the consistency of open APIs and with SAP’s other policy of indirect access.

Video Introduction: Are SAP’s REST/JSON APIs Real?

Text Introduction (Skip if You Watched the Video)

SAP has been telling customers that they are bringing out a large number of REST/JSON APIs. What is curious, because SAP deliberately makes their products difficult to integrate to block out competing vendors, so that their customers will buy only SAP applications, using integration problems as a method of scaring the customers into a situation of complete lock-in and allowing them to take control over the spend of their customer. Furthermore, SAP routinely makes false claims about SAp integration. You will learn about our estimation of the likelihood of these APIs becoming prevalent.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Lack of Financial Bias Notice: We have no financial ties to SAP or any other entity mentioned in this article.

  • This is published by a research entity.
  • Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. 

The Question

“In recent discussions with SAP they have talked about web services becoming more standard and even mentioned 3000 REST/JSON APIs that are available on the platform (not sure which version?) and that is certainly a technology that my team has been ready for and would like to leverage.

That said, I’m not seeing signs of the many APIs that were reported.

Have you seen any research on SAPs ability to deliver this technology? Is it still in the works? Is there any customer adoption?”

The Analysis

This plan has not been brought to my attention. But there are several reasons to be skeptical.

SAP’s History of Restricting Integration

SAP has always made it difficult to connect to SAP. This is an intentional strategy designed to direct companies to SAP products. SAP has made numerous statements about making integration easier over the years, but it has tended to stay the same. This is one of the reasons that companies that use SAP have such a high IT overhead. Not only is integrating to SAP difficult, but merely extracting data from SAP is more complicated than any other ERP system because SAP does not allow customers to direct access tables, as do all other ERP vendors.

SAP uses the logic that application integration is so problematic that companies should not connect non-SAP applications to SAP applications. This allows SAP to argue that using all SAP applications makes an overall implementation work better.

This allows SAP to not compete on the actual application but to compete as part of an ecosystem.

The Outcome for SAP Customers

The paragraph above has been the long-term SAP strategy, and most SAP customers believe it, using non-SAP systems only when they find a huge hole in SAP’s offering. This has lead to deleterious effects for SAP customers as they have loaded up on weak applications ranging from the SAP BW to SAP APO. These applications continually consume large amounts of IT resources and deliver low levels of business value. However, this point is not admitted to by IT departments, as IT departments will almost always have “SAP’s back” even when it works against the companies’ interests that employ them.

The Reality of SAP Integration

The only applications that are naturally integrated, or sits on the same database, is SAP’s ERP system. All other SAP applications need to be connected to the ERP system and other SAP systems with adapters. SAP gives the impression that all their SAP applications are naturally integrated, but the customer soon learns that this is not true. The truth is that SAP is not very good at developing adapters. For example, SAP’s integration product called PI is drastically inferior to other integration applications such as those put out by Informatica (as just one example).

In addition to integration limitations with SAP developed applications, SAP has proven to be quite slow in developing adapters to its acquired applications (SuccessFactors or Ariba). It is quite common for applications that were acquired over five years ago to have integration problems still.

The Consistency of Open APIs + Indirect Access?

If SAP is opening up technically, why are they closing down access from the legal side?

Every one of those 3000 APIs is a potential indirect access violation.

According to SAP, SAP account executives are “not trained on indirect access,” so they can introduce the APIs one month. Then an “indirect access expert” can show up a year down the line and say, “these connections are all indirect access violations, and you owe us $XXX.” There is no what to know if that would happen. SAP applies indirect access selectively.

None of my customers are using these APIs, and SAP is always introducing new things, so if they are new, we don’t know if they will take. This is the official site/pages for the APIs

SAP to Non-SAP Integration

SAP and virtually anyone that makes money from SAP has an interesting perspective on the wisdom of using non-SAP systems along with SAP. This is the official story on SAP integration, which tends to differ significantly from the reality of SAP integration. You will learn about our analysis of this narrative.

SAP’s Story and Position on Integrating Non-SAP Systems to SAP

I believe I can represent SAP’s position on this topic accurately. Anyone who disagrees with SAP is free to correct my interpretation, but SAP has told me this on some occasions.

  • SAP’s Amazing Best Practices: SAP maintains a catalog of Best Practices that it incorporates into its software. All of SAP’s software is based upon Best Practices, and because SAP is so widely deployed, it contains all Best Practices. I have an article that analyzes the best practices claims in this article. That is the first part of the argument.
  • Integration to Non-SAP Systems Must be Avoided: According to SAP, or virtually anyone who makes money on SAP, integration is so complicated that you should not integrate any non-SAP system to SAP. SAP will concede that some best of breed applications may be slightly better. But any business benefit received from using a non-SAP system is immaterial because you will any business benefit will be overcome by such substantial integration costs. In cases where SAP does not have a solution, it makes more sense to wait until SAP brings out one. As stated, it is simply too risky to connect a non-SAP system to SAP.
  • Connecting Non-SAP Applications to SAP Comes with Legal Liabilities Due to Indirect Access: Furthermore (and this is a recent addition), if you don’t buy all SAP applications, you face indirect access liabilities. Therefore you should be careful not to try to purchase non-SAP applications because it is so risky.

The Reality of Integration Versus the SAP Presentation

This is sort of the problem in enterprise software, where it’s all about quota attainment. You can’t get an opinion or advice without getting a biased answer. But the problem with the viewpoints of SAP, SAP consulting companies, and independent SAP consultants is that there is no evidence that application integration is a worse trade-off than customization. Secondly, all of those that draw money from SAP overstate the degree of integration among SAP’s applications. In SAP APO, the integration harness called CIF has a very high overhead. Integration issues do not simply go away, as is implied in the SAP sales process.

Problems with SAP’s Integration Between Its Applications

I continuously receive complaints about the poor integration between SAP’s newly acquired products like SuccessFactors, Concur, etc.. Outside of ERP, a multi-module system that is completely part of one database, all of SAP’s other applications required integration harnesses. Anyone can develop an integration harness, and most vendors have some type of integration to ECC already.

Cost Estimation for Various Solution Architectures

My experience and time spent quantifying the costs of software and working on implementations are that the number one feature to look for in software is its actual inherent capabilities and how well it meets business requirements. Unfortunately, I have done it myself for those that would tell me how horrible application integration is. I have created integration harnesses from scratch as part of integration teams.

And I did not even get to use excellent tools like Informatica. And secondly, what you get out of SAP regarding integration between its applications is not much different than what other vendors offer regarding connecting to SAP.


Articles are going back to 2013 on SAP APIs, and if they are not “a thing,” by this time, they probably won’t be.

So overall, it sounds extremely fishy. If the response requests for real information are that “it is coming,” it is probably fake. There has been a tremendous amount of lying and incorrect information about what is going on behind SAP integration scenes. This observation has come from the detailed study that, frankly, virtually none of the SAP entities I presented above have done themselves. Secondly, it comes from a point with no financial bias. SAP and their surrogates make their claims about integration not because they are true but because it makes them the most money.

To find out about SAP’s API management, see the article How Useful is SAP API Management?