Release contracts: C0 / C1 / C2 / C3
What you'll learn
C1 = released and upgrade-stable (safe to use); C0/C2/C3 = internal, unstable, or deprecated (don't build on them).
- C0 not released · C1 released (cloud-safe) · C2 use-system-internal (unstable) · C3 deprecated.
- Only C1 is safe to consume from a Clean Core package.
- API State is visible per object in ADT and browsable at api.sap.com.
Every SAP object carries a Release Contract (its API State), visible in ADT object properties. C0 means not released — internal, touch at your own risk. C1 means released for Cloud Development: stable across upgrades within the contract, safe to consume from ABAP Cloud.
C2 means 'use system-internal' — sometimes documented, but not stable across upgrades, and not for custom Clean Core code. C3 means deprecated, and ATC reports its use; the long text usually names the successor in a 'Replaced By' field.
API State shows on classes, interfaces, function modules, CDS views, BAdI definitions, and DDIC types. Browse released objects under the system node in ADT, or the catalog at api.sap.com. A subtle trap: a released FM that returns a C2-typed structure surfaces that type into your code — and your reference to it is itself a violation that ATC catches under the cloud variant.
Key points
- C0 not released · C1 released (cloud-safe) · C2 use-system-internal (unstable) · C3 deprecated.
- Only C1 is safe to consume from a Clean Core package.
- API State is visible per object in ADT and browsable at api.sap.com.
- A C1 API can still leak a C2 type — consuming that type is a violation ATC flags.
Examples
In ADT, open the object → Properties → API State. 'Released' (C1) is the green light; 'Use System-Internal' (C2) and 'Deprecated' (C3) are not.
Source notes: clean-core-curriculum §1.4
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.