# Every SAP System Has an Undocumented REST API

SAP's Eclipse tooling talks to every SAP system over an undocumented REST API, and a 404 from it can mean three different things.


The first time I pointed a browser at /sap/bc/adt on a client system, it came back 404, and the 404 looked exactly like the URL did not exist. It was not the URL. It was a service node nobody had switched on.
That single discovery is most of what this post is about, because it explains something bigger than one troubleshooting step: every SAP system running the ABAP Development Tools integration is quietly running a REST API, and there is no proper manual for it.
Why the API exists at all SAP’s own Eclipse-based development environment, ADT, does not talk to the backend over the old SAP GUI protocol. It talks HTTP. Under the hood there is a REST-style interface exposed through the ICF handler at /sap/bc/adt, and Eclipse’s tooling calls it the way any HTTP client would - GET a resource, PUT a change, read the response back. That is the whole reason Flexible ABAP, my JetBrains plugin, can exist without a SAP GUI license or an RFC connection: if Eclipse can talk to your SAP system over plain HTTP, so can anything else that speaks the same dialect.
“The same dialect” is the catch. Beyond a Java SDK meant for building Eclipse tooling, there is no comprehensive official documentation of what actually lives under /sap/bc/adt - that assessment comes from an SAP Community thread I checked while building this, not from SAP itself, and I want to be clear that community knowledge is exactly what it is: people who reverse-engineered the same thing I did, comparing notes.
The 404 that means three different things Here is where it gets genuinely annoying. /sap/bc/adt requires SAP_BASIS 7.31 SP04 or later, and it has to be explicitly activated in transaction SICF, along with its own /sap/bc/adt/discovery child node - again, per community documentation rather than an official SAP statement, because I could not find one. Until someone flips that switch, every request to the endpoint returns 404.
The problem is that a 404 from an unactivated ICF node looks identical to a 404 from a URL that simply does not exist. There is no error code that says “this is real, somebody just forgot to turn it on.” You cannot tell the difference from the HTTP response alone. You find out by knowing to go look in SICF, under default_host, then sap, then bc, then adt, right-clicking, and activating the service and its sub-nodes - which is exactly the process I ended up writing into Flexible ABAP’s own connection guide, because I kept explaining it in support emails and got tired of retyping it. The guide’s troubleshooting section exists specifically because “the host was reached, but the endpoint was not found” and “the endpoint does not exist” are indistinguishable until you check.
Once the node is active, the rest is ordinary REST work: authenticate, GET a program’s source, PUT your edit back, read the response for compile errors. None of it is exotic. The whole difficulty was ever getting past that first 404, because nothing on the wire tells you whether you are looking at the wrong URL or the right URL turned off.
What fifteen years of enterprise integration teaches you about this I have spent a decade and a half building software that talks to systems it did not design - Java against SAP, against Oracle, against whatever core platform a client happened to run that year. The lesson repeats everywhere: the vendor’s own tooling almost always talks to the backend over some sane protocol, and almost never publishes what that protocol is, because the tooling was the product, not the wire format underneath it. ADT is a clean example because the REST shape is right there, visible in every request Eclipse makes, and still effectively undocumented outside what the community has pieced together by watching.
The honest cost Building against an interface nobody documented and nobody promised to keep stable means it can change under you, and you find out from a bug report, not a changelog. SAP owes me nothing here - there is no contract, implicit or otherwise, that /sap/bc/adt looks the same at the next patch level as it does today. Flexible ABAP works because Eclipse’s own tooling depends on the same surface staying reachable, which is a better guarantee than a public API contract would be, but it is still not the same thing as one. I would rather build on this than not have ABAP support at all. I just do not pretend it is documented.