Skip to Content
Product Information

Integration User for Odata services in SAP Cloud for Customer

Dear Community members,


Note: Current post strictly provides steps for SAP Cloud for Customer (SAP Sales Cloud and SAP Service Cloud).

With the 1911 release of SAP Cloud for Customer, SAP has provided capability to use integration or technical user for Odata services.

Odata Services – 1911


With A2X services being deprecated from February 2020, customers and partners are requested to move their A2X and SOAP services to Odata. But with Odata services we have had to use basic authentication with a Business User. This causes concerns when the password expires, leading to failure of the integration.

You can read more on this here.


Below, we will see how we can use a technical user for basic authentication and Certificate based authentication for Odata services.


Create a new Communication system. Maintain the host name.


Create Communication arrangement for standard Communication Scenario: OData Services for Business Objects

Select the services which you wish to enable under technical data. In the next image you can see that the technical user is generated.


The technical user created above can be used for basic authentication as well.

Further, we have similar steps as with SOAP services.

Click on edit credentials and create and download a key pair. (a *.p12 extension file will be downloaded)


Add the key pair file to your CPI tenant under manage keystore.


Configure the Odata adapter as follows.

Maintain the address of the service you wish to call, and the alias saved in the previous step.

Select authentication method as Client Certificate or Basic authentication.


Note: CSRF token is not needed as we are using a technical user.

In case of Client certificate, provide the name of the *.p12 file which you saved in keystore.

In case of Basic authentication, deploy a credential artifact in CPI with the technical user created above, and provide the credential name.


Download the edmx file from the metadata URL.$metadata

and configure the request query.


Using a technical user provides better security and prevents failure of integrations due to expiration of password.


You can get more details on this here.



For certain services like: accounthierarchylist, businesspartnerrelationship… if you use CSRF token, you’ll get error “Inconsistent Authorization: Re-activate Communication Arrangement.” This is because such services don’t have WoC view and hence reading metadata causes issue.



Praveen Dwivedi

You must be Logged on to comment or reply to a post.
  • In case anyone runs into the same issue that I did:

    • when you go into the settings of the Communication Arrangement, under Services Used – you might not see all of your custom OData services
    • go into OData Service Explorer, edit the corresponding service
    • expand the Header and assign a WOCV

    I know it’s counter-intuitive because the technical user does not have a business role, i.e. no restrictions, but at least it works.

  • Hi Praveen Kumar Dwivedi ,

    Firstly, thanks for the excellent blog. I wish this was documented in the C4C guides too.

    You have an edit on your blog where you mentioned about error “Inconsistent Authorization: Re-activate Communication Arrangement.

    I am getting this error for my custom OData service – despite I have assigned it to the communication arrangement.

    I get this error only when I do a GET to my custom OData with Technical User (maintained for the communication arrangement). The Authentication is Basic and with User ID and Password defined on Communication arrangement. When I test with POSTMAN, I get the same error.  But if I user the GET via POSTMAN with any other business user details , I do not get this error.

    The test on custom OData via OData explorer is also fine. So means, system has a problem only when I do a GET on my custom OData with technical user.

    Do you know how to solve this error ?



    • Hi Suchita, This issue occurs when no WoCView is assigned to the service.

      Check if WoCView is assigned to your custom Odata service entity types.

      Alternatively, you are fetching CSRF token to GET data, this is not needed for technical user. Remove CSRF token fetch.

      • Hi Praveen Kumar Dwivedi ,

        Thanks for your reply .

        My issue is now solved. There are two placed for WoCV assignment on OData – on Header and on Property. I was doing it only on Property and that was it problem (as header is always collapsed so didn’t realised it) .

        The got resolved once the header WoCV is maintained.



    • Hi Maxime

      Being on the same architecture, it should be possible. Although, I haven’t tried it in a ByD system.

      Hopefully you must have already tried it out already by now.