Is the SAP Object Your Z Program Uses a Released API?

Suppose a fictional Z program reads the country table T005 directly. As soon as clean core comes up, someone asks whether that SAP object is a released API. After reading this note you can tell what makes an API "released", how to check an SAP object's release state in ADT and in SAP's published lists, and why custom code that leans on unreleased objects becomes a burden at upgrade time, so you can decide what to fix first.

The program ZDEMO_API_STATE is invented, and the code was not run on a real system. The release states of SAP objects come from the Cloudification Repository files that SAP publishes on GitHub, downloaded on 2026-10-21. The concepts follow the ABAP Keyword Documentation 7.58, the ADT screens follow the ADT guide for ABAP Platform 2025 FPS02, and the clean core levels follow an SAP Learning course. Lists and screens change from release to release.

A released API carries two classifications: a contract and a visibility

ABAP supports two main development models, classic ABAP and ABAP Cloud. Standard ABAP, the language version of classic ABAP, places no restrictions on access to other repository objects besides the package concept. An object written in ABAP for Cloud Development, the language version of ABAP Cloud, can use only APIs released for that language version, apart from a few allowed cases such as objects in the same software component.

A released API is a repository object, or part of one, that is released for access in ABAP Cloud, and the release needs two classifications together. The first is a release contract, which sets the consistency and compatibility rules for later changes. When repository objects of certain language versions access released APIs, the only contract that matters is C1 (use system-internally). The second is a visibility, which makes the object visible to a restricted language version such as ABAP for Cloud Development or ABAP for Key Users.

The C1 contract forbids incompatible changes to components that are already visible, such as parameters, elements or CDS associations, while leaving room to add optional components later. A C1 object must not be deleted once released, but it can become deprecated. Even so, the contract does not promise full downward compatibility, so consumers have to write code that tolerates the allowed changes to avoid errors after an upgrade.

SAP NOTES

A released API carries two classifications

Per ABAP Keyword Documentation 7.58 and the ADT guide

1. 01

   Release contract

   C1

   • Sets the compatibility rules for changes
   • C0 extend · C1 use system-internally · C2 remote API, and more
   • Access from certain language versions: C1 only
2. 02

   Visibility

   Use in Cloud Development

   • Sets which restricted language version sees it
   • ABAP for Cloud Development
   • or ABAP for Key Users
3. 03

   Released API

   API State: Released

   • Both are needed for use in ABAP Cloud
   • A C1 object must not be deleted; it can become deprecated
   • Full downward compatibility is not promised

Standard ABAP, the classic ABAP version, places no restrictions on access besides the package concept.

Where to check one SAP object's state

Inside the system, the API State tab in an object's Properties view shows its release state; the tab appears only for object types that can be released as APIs. Released means a public API for the purpose its release contract defines. Deprecated means it is still a public API but should no longer be used and should be replaced by its successor. An object that has been deprecated for at least 12 months can be set to the final state Decommissioned, after which it cannot be used productively.

For many objects at once, create a new ABAP Repository Tree in the ADT Project Explorer and choose the Released Objects or Deprecated Objects filter. Entering api:USE_IN_CLOUD_DEVELOPMENT as a property filter lists the objects released with the C1 contract and the visibility Use in Cloud Development. The program ABAP_DOCU_RELEASED_APIS lists the repository objects of the current system that carry a release contract.

Outside the system, SAP publishes the Cloudification Repository in the GitHub repository SAP/abap-atc-cr-cv-s4hc. Its JSON files list the released APIs and also the objects that are not released, with successor objects where they are specified. SAP Cloud ERP Private and on-premise systems can use the files with PCE in their names; the latest PCE file is valid only for the latest SAP Cloud ERP Private version, so check the README for the file that fits your release.

SAP NOTES

Three places to check one SAP object

ADT 2025 FPS02 · ABAP 7.58 · SAP's public lists

• API State tab in ADT

  Properties > API State

  • One object's state in the Properties view
  • Released: use it for its contract's purpose
  • Deprecated: switch to the successor
  • After 12+ months as Deprecated, it can be decommissioned

• Lists in the system

  api:USE_IN_CLOUD_DEVELOPMENT

  • Released Objects in an ADT repository tree
  • The api: property filter picks contract and visibility
  • Program ABAP_DOCU_RELEASED_APIS

• SAP's published lists

  T005 -> I_COUNTRY

  • The Cloudification Repository on GitHub
  • Also lists unreleased objects, with successors where given
  • Cloud ERP Private and on-premise can use PCE files
  • The latest PCE file fits the latest Cloud ERP Private

States are taken from the files downloaded on 2026-10-21. Check again for your own release.

In the latest PCE file downloaded on 2026-10-21 (objectReleaseInfo_PCELatest.json), the entry for T005 has the state notToBeReleased, and its successors list the CDS entity I_COUNTRY, whose own state is released. The SAP Learning course on SAP S/4HANA Cloud gives the example that reading T005 in ABAP Cloud development raises a syntax error telling you to use I_COUNTRY instead. In a Standard ABAP program the same SELECT is not blocked, so you have to look the state up separately.

What depending on unreleased objects leaves for the upgrade

In ABAP Cloud, changes to released APIs are strictly governed by the release contracts described above. Unreleased objects come with no such promise. The SAP Learning clean core course treats SAP internal objects, which are neither released nor nominated as classic APIs, as subject to change without notice or compatibility guarantees. Z code that relies on them leaves you checking, before an upgrade, whether those objects changed. The same course also says classic extension techniques can make upgrade projects more disruptive than necessary.

Not every unreleased object carries the same risk. The same course sorts extensions in SAP S/4HANA Cloud Private Edition and on-premise into four levels. Level A uses only released APIs and extension points, and an on-stack extension must be built with key user or developer extensibility tools and the matching ABAP language version. Level B uses only classic APIs, which SAP nominated despite their having no formal stability contract, and released APIs; its examples are ALV built with CL_GUI_ALV_GRID, and Standard ABAP custom objects that reference no restricted or unsupported SAP objects. Level C uses other internal objects, for example read-only access to SAP tables that are not endorsed for external use. A changelog for SAP objects was introduced to help manage level C risks, and its features include automated ATC checks that find incompatible changes in custom code. Level D uses what is marked as not recommended, such as modifications, implicit enhancements and unsupported writes to SAP tables. An extension is rated by the lowest-ranked technology it uses.

The same repository's classic API classification file (objectClassifications_SAP.json) holds the states classicAPI and noAPI, and noAPI marks level D objects. In the 2026-10-21 files, CL_GUI_ALV_GRID is a classicAPI. T005 is not released and is not in that file either, so by the level definitions ZDEMO_API_STATE, which reads T005 directly, lands in level C. Replacing T005 with I_COUNTRY would not make it level A, because it is a Standard ABAP program; by the same definitions it would be level B.

SAP NOTES

Clean core levels A to D

Extensions in SAP S/4HANA Cloud Private Edition and on-premise

• A · Released APIs

  ABAP for Cloud Development

  • Uses only released APIs and extension points
  • Covered by stability contracts
  • On-stack: built in the matching language version

• B · Classic APIs

  CL_GUI_ALV_GRID

  • Objects SAP nominated as classic APIs
  • No formal stability contract
  • Also Standard ABAP objects without restricted or unsupported references

• C · Internal objects

  SELECT * FROM t005

  • Neither released nor nominated as classic APIs
  • Can change without notice
  • Example: the sample's direct T005 read

• D · Not recommended

  state: noAPI

  • Modifications and implicit enhancements
  • Unsupported writes to SAP tables
  • Objects marked noAPI

Per the SAP Learning clean core course. An extension is rated by the lowest-ranked technology it uses.

Many programs: use the ATC check

The Cloudification Repository's JSON file is the content of the ATC check "Usage of Released APIs (Cloudification Repository)". With it, you can analyze existing custom code for its use of released and unreleased APIs on all ECC and S/4HANA releases. You switch the check on in a check variant and enter the file's address in its attributes. For SAP Cloud ERP Private, the check Usage of APIs under Clean Core takes a PCE file. The README names the SAP Notes you need and the SSL setup.

The ATC check API_USAGE, part of the check variant ABAP_CLOUD_DEVELOPMENT_DEFAULT, also finds uses of deprecated objects, but it reports only objects in ABAP for Cloud Development or ABAP for Key Users. For existing Z programs written in Standard ABAP, the Cloudification Repository check is the better fit.

One thing to do today: pick one Z program you change often and write down the SAP objects it reads or calls directly. Then search the PCE file for each object's name, write its state and successors next to it, and look up any object missing from that file in the classic API classification file. A line with a successor is the first candidate to fix next.