Skip to Content
Product Information

SAP Cloud Integration – Step towards Building API Based Integrations


The below described API artifacts availability depends on your tenant licensing model, more information at

Due to unavoidable reasons, the release of below mentioned feature is postponed to next release cycle. Hence, the below mentioned feature will be available with  SAP Cloud Integration version 3.34.*/5.18.*/6.10.* . Updated the blog post’s introduction part accordingly. Initially it was planned to release as part of version 3.33.*/5.17.*/6.9.*.

Only renamed type OData API from OData Service will reflect in 3.33.*/5.17.*/6.9.*.


SAP Cloud Integration, one of the capabilities of SAP Integration Suite, brings a new feature from version 3.34.*/ 5.18.*/ 6.10.* which takes a step towards strengthening design of API based integration scenarios. In this blog post, information about this new feature will be provided.


Users can now create a new integration artifacts of type REST API, SOAP API and OData APIs. OData APIs are the rename of previous OData Services artifacts. These artifacts generate a default integration template which can be further extended to meet API based integration needs.


API Artifacts Menu


Note: We are fixing the sorting of these menu entries 🙂


Once you select the menu entry, creation dialog will popup


Select REST API to create an REST API based integration scenario.


Create REST API Artifact


Once you create REST API integration scenario gets created



Clicking on the artifact, integration with basic template is displayed. For REST API, HTTPs sender adapter is added in the template.


REST API Integration Template


Add the required endpoint address name fo the HTTP sender adapter. The template can be further extended to fit your API integration scenario


REST API with HTTP Sender Adapter



Select SOAP API to create an SOAP API based integration scenario.


Create SOAP API Artifact

Once you create, SOAP API integration scenario gets created


Clicking on the artifact, integration with basic template is displayed. For SOAP API, SOAP 1.x sender adapter is added in the template.


SOAP API Integration Template



SOAP API with SOAP Sender Adapter


Note: OData API is the renamed type of previous OData Service

Select OData API to create an OData API based integration scenario.


Create OData API Artifact


Once you create, OData API integration scenario gets created


Clicking on the artifact, integration with basic template is displayed. For OData API, OData V2 sender adapter is added in the template.



For OData API artifact, a default method and a sample EDMX file is generated in the template




Once you extend the API templates and complete the integration scenario, you can save and deploy them.

Deployment View

To view the deployed artifacts, as of now, monitoring doesn’t provide a default tile to view the deployed artifacts, you need to create a tile to view them.

Add a tile under Manage Integration Content


Add new tile in Manage Integration Content section



Select API type for tile




Clicking on the tile displays the details


Message Processing view

To view the message processing status for APIs, you need to add the tile under Monitor Message Processing section


New tile under Monitoring Message Processing section




If user invokes API endpoint, e.g., a REST endpoint from POSTMAN application, then message processing status will appear in this new tile



Invoke REST API endpoint




Details of the message processing details



  1. If you have already deployed the previous OData Service artifacts and created a tile for it, then such previously created tile will be appear as OData APIs.
  2. You can repeat the same process to get a tile for SOAP API artifacts by choosing SOAP API type for new tile


Next Steps

As mentioned, this feature is a step towards building API based integration scenarios. And there are more supporting enhancements coming.

Considering API Definition

As of now, you might have noticed, in REST API and SOAP API based integration scenarios doesn’t take API definition (e.g., Open API Spec/Swagger JSON for REST API) as source. In the next upcoming increment, implementing an integration considering API definition file shall be supported.

Enhancing the templates

For API based artifacts, the sender adapter selection and validation will be enhanced to match the type of artifact, e.g., only HTTPs adapter as sender for REST API artifact.



This is an initial step towards strengthening SAP Cloud Integration capability to support building API based integration scenarios. As of now, they are integration artifacts with basic templates, but going forwards, more and more API related capabilities shall be added.

You must be Logged on to comment or reply to a post.
  • Thanks for your blog,


    But I don't see the value added of creating an artefact type "API" instead of creating an Iflow starting with a sender "API" (rest,soap...) ?

    Because the predefined template of this flow is not really a value added. it's only few click to get the same result starting from Iflow artifact...


    Is it a way to better onboard the API management APIs for the future ?

    • Hi Aurelien,

      Thanks for the feedback. As I have mentioned, these are the initial steps for us in SAP Cloud Platform Integration to create a technical baseline on the API based integration.

      And yes, in upcoming releases, we have the plans to bring SAP API Management closer to SAP Cloud Platform Integration.




  • Hi Deepak,

    These are not any new capabilities right? Except the options to create templates for Rest, SOAP and additional tiles in monitoring, these still creates integration flows even though the type changed.

    Swagger documentation based API generation is cool but this is already a feature available in API Management and generating APIs based on that code. When clients asked for a Rest API, we use HTTP sender adapter and create an iFlow.

    Further more enhancements like supporting multiple HTTP operations similar to OData service under a single API would be helpful. Thanks for the effort on writing this blog.

    • Hi Anil,

      Thanks for the feedback. As I have mentioned, these are the initial steps for us in SAP Cloud Platform Integration to create a technical baseline on the API based integration.

      And yes, going forward, supporting multiple HTTP operations as similar to OData API (the renamed OData Service artifact) under a single API is in our plan and once available, I will share the updates via blog.




  • Thanks for sharing the new features in advance.

    Is this baseline features releasing soon or it will release later with more capabilities?




  • Hi,

    I see that once you have defined a type of e.g. Integration Flow you cannot change into REST API anymore.  I have approx. 20 Integration Flow I want to redefine as REST APIs.

    Best regards,

    Marco Verhoef

    • Hi Marco,

      As of now, there is no option to convert Integration Flow to REST APIs, but this is something that we are working on to enable to support.

      Once such a feature is enabled, you will be notified via release notes, documentation and I will update/create a relevant blog.




  • I don´t fully get the idea. At the end it looks like an overlapping feature with SAP API Mgmt. service.

    Why would I create APIs in CPI, when API mgmt. service can do that for me easily, meaning exposing backend services or CPI iFlows as API end points. could you please shed some light here?

    • Hi Jitendra,

      In API Management, you don't 'implement' the API, but you only 'manage' them. So, this is the first step from CPI side to come up with REST/SOAP API Artifacts, such that, you can implement an API.

      As of now, with this first step and via Integration Flow, e.g. with HTTP sender, you will define the integration scenario which can be equated to the API implementation, but with the "API definition" file.

      Going forward, our next step is, we will allow you upload/create API definition file/Swagger file in SAP Cloud Integration REST API artifact, and you would then be able to use that definition file to implement the scenario with supported back-end services

      I hope this clarifies