Released APIs and SAP Business Accelerator Hub

An object is released when its release state is Released under a specific release contract, which defines the permitted use and the changes SAP will avoid:

A Deprecated object still works but should be replaced by its successor; a Decommissioned object is no longer supported, a state SAP currently applies only to remote APIs. For C0 and C1 objects, a visibility setting decides whether ABAP Cloud developers, key users or both may use the object.

A released API is therefore a promise about one object and one purpose, not a general label for anything with an interface.

The SAP Business Accelerator Hub, formerly the SAP API Business Hub, is a web application hosted by SAP. It catalogs SAP and partner APIs (OData, SOAP, REST), business events, CDS views, data products, integration flows and process blueprints.

For each API, the hub shows the specification, the documentation and, for many APIs, a sandbox for trying calls before any system is connected. A developer at Alder Manufacturing who must create supplier invoices from an external portal starts here: find the API, read its status and successor, test it in the sandbox, then download the specification.

Two limits matter. The hub documents SAP's standard APIs, not customer-specific ones, and APIs are listed per product, so an API listed for one edition is not automatically available in another. The SAP Business Accelerator Hub is the starting point for remote API design, not proof that an API exists in a given system.

Released APIs fall into two practical groups:

• Local APIs (contract C1). Released CDS views, classes, behavior definitions and other objects used by custom ABAP code in the same system. ABAP Cloud code may call only these. Developers find them in ABAP Development Tools, where the API State tab shows the release state and contract, and in the developer extensibility section of the Business Accelerator Hub.
• Remote APIs (contract C2). OData, SOAP and other services called over the network by SAP BTP apps, middleware or third-party systems. They are documented on the Business Accelerator Hub.

When SAP replaces an API, the old one is deprecated and a successor is named; SAP deprecated the Production Order OData API in SAP S/4HANA Cloud 2008, for example.

The distinction decides the architecture: local APIs serve on-stack extensions built with ABAP Cloud, while remote APIs serve side-by-side extensions and integrations.

• SAP S/4HANA Cloud Public Edition: released APIs are the only way in. Custom ABAP code uses local released APIs only, and remote APIs are exposed through communication scenarios that an administrator activates with a communication arrangement.
• Private Edition and on-premise: released APIs coexist with classic interfaces such as BAPIs. Remote OData APIs are activated like other OData services on SAP Gateway, for example with /IWFND/MAINT_SERVICE for OData V2. Where no released API exists, SAP's guidance allows custom wrappers around listed classic APIs, released with contract C1.
• SAP BTP ABAP environment: the same release contracts apply, and custom objects used across software components are either released or connected through software component relations.

Customers can release their own objects only with contracts C0 and C1. The concept of a released API is identical across editions; what differs is how much non-released access each edition still tolerates.

• Upgrade stability by contract. SAP checks delivered objects against their release contract, so incompatible changes to a released API are not expected in an upgrade.
• Enforcement, not only advice. In ABAP Cloud, the compiler rejects calls to objects that are not released for cloud development, which turns the clean core rule into a syntax check.
• One vocabulary. The same states and contracts apply in every SAP S/4HANA edition and the SAP BTP ABAP environment.
• Planned change. Deprecation with a named successor gives teams a migration path instead of a broken interface.

Released APIs are the dependency rule on which level A of the clean core classification rests.

• Coverage is uneven. Not every business object or field has a released API. A frequent complaint in practitioner communities is finding the needed operation only in a classic BAPI or an internal table.
• A contract is not a design. A released API guarantees technical stability, not that its granularity fits a process; several calls may be needed for one business step.
• Behavior can still change. SAP's contract rules allow compatible changes to released APIs and do not promise full downward compatibility, so consumers must retest after upgrades.
• Deprecation is easy to ignore. Deprecated APIs keep working for a time, so the switch to the successor tends to slip.

Released APIs remove upgrade risk from the interface; the fit to the process and the lifecycle of each consumer remain the team's responsibility.

1. Assuming every OData service is an API. An OData service generated for one SAP Fiori app is a UI service. Check the release state before an integration depends on it.
2. Designing from the hub alone. Confirm the API exists and is activated in the target system and release.
3. Ignoring deprecation notices. Track successors for every API in use.
4. Wrapping everything. Custom C1 wrappers around classic APIs bridge gaps; each needs an owner and a review when SAP releases a successor.

The practical decision criterion is simple: if the object has no release state for the intended use, treat any dependency on it as technical debt and record it.