How to use the OAuth2 client-credential flow?

description: "Client credential flow for the OAuth2 authentication"

How to use the OAuth2 client-credential flow?

Starting with SKYVVA SAP PI/PO connector module v2.3.6, you can authenticate from SAP PI/PO to Salesforce using the OAuth2 Client-Credentials flow in addition to the existing Username-Password flow. This article explains when to use it and how to configure it.

Why we added this flow

Salesforce no longer supports the legacy Connected App for new technical integrations. The replacement, the External Client App, supports only the Client-Credentials flow. If you are setting up a new Salesforce integration today, or your Salesforce administrator has migrated an existing integration to an External Client App, you must use this flow — Username-Password authentication is not available there.

Existing channels using Username-Password against a Connected App continue to work unchanged. The two flows run side by side; a single channel parameter (OAuth2Flow) selects which one applies to that channel.

Prerequisites

1. Salesforce — External Client App

Create an External Client App in Salesforce, enable the Client-Credentials flow, and assign a Run-As user. The detailed steps live in the Salesforce documentation — this is a Salesforce-side setup and not a SKYVVA feature, so we don't duplicate Salesforce's documentation here. After the app is created, copy the two values you will paste into the SAP PI/PO channel:

• Consumer Key (the OAuth client_id)
• Consumer Secret (the OAuth client_secret)

https://<your-domain>.my.salesforce.com/services/oauth2/token

For sandbox orgs, replace the host with the sandbox my.salesforce.com host that Salesforce assigns to your org. The path (/services/oauth2/token) is the same in production and sandbox.

2. SKYVVA managed package on Salesforce

The v2.3.6 module reads a new custom field on the SKYVVA Interface object to determine the per-interface API retry budget:

skyvvasolutions__Max_Number_Of_API_Retry__c

If your Salesforce SKYVVA managed package version is older than the version that ships this field, add the field manually before deploying v2.3.6 to your SAP PI/PO system. Default value 0 (no extra retries beyond the automatic INVALID_SESSION_ID renewal).

3. SAP PI/PO — V3 receiver channel

This article assumes you already have a working V3 receiver channel using the Skyvva/V3/RestIntegration module. See How to Setup the SKYVVA Module Parameters in SAP PI/PO with V3? for the base setup. The Client-Credentials flow only changes which authentication parameters the channel reads — everything else (Operation, BulkPackageSize, payload format, interface, integration) is unchanged.

Channel parameters

Open your receiver channel's Module tab and configure the parameters below. The table is split into three groups: (a) parameters that select the flow, (b) authentication parameters specific to each flow, (c) parameters shared with the existing V3 setup.

Important: parameter names are case-sensitive. Copy them exactly from this table.

Flow selector

Authentication parameters

Shared with V3 base setup

These exist in your channel already if it follows the V3 setup. They are unchanged for Client-Credentials.

Screenshot example

About ConsumerKey vs. the legacy ConsumeKey name

Older SKYVVA versions read this parameter under the misspelled name ConsumeKey (missing the trailing r). Both names are accepted in v2.3.6 — the canonical name ConsumerKey is preferred (it matches the sibling ConsumerSecret), but channels using the legacy name keep working and emit a one-line deprecation message in the audit log. You can rename the parameter at your convenience.

Migration from Username-Password to Client-Credentials

If you have an existing channel using Username-Password and your Salesforce administrator wants to switch to Client-Credentials:

1. Get the Consumer Key and Consumer Secret from the External Client App in Salesforce.
2. On the receiver channel's Module tab:
   • Add or set parameter OAuth2Flow to Client-Credentials.
   • Replace ConsumerKey and ConsumerSecret with the External Client values.
   • Update AuthorizationServerURL if it currently points at the SOAP login URL — change it to https://<your-host>/services/oauth2/token.
   • You may leave SforceUsername and pwdSforceLoginPassword in place (they are ignored), or remove them.
3. Save and activate the channel.
4. Send a test message and confirm success (next section).

Verify success in the audit log

Send a test message and inspect the receiver channel's audit log. A successful Client-Credentials run shows these log lines (line numbers omitted for clarity):

skyvva_v2.3.6/SKYVVA/...RestIntegrationV3.4: Begin session handling (SKYVVA version 2.3.6)
skyvva_v2.3.6/SKYVVA/DisplaySAPChannelParams.1: [INFO] SAP-PO channel parameters:
  OAuth2Flow: Client-Credentials
  AuthorizationServerURL: https://<host>/services/oauth2/token
  ConsumerKey: <your-key>
  ...
skyvva_v2.3.6/SKYVVA/...RestIntegrationV3TransLogic.1: Begin transformation
skyvva_v2.3.6/SKYVVA/com.skyvva.xml.RestIntegrationV3TransHandler.4: (getNewSalesforceContainerPooling) check deadlock
skyvva_v2.3.6/SKYVVA/com.skyvva.xml.RestIntegrationV3TransHandler.5: (getNewSalesforceContainerPooling) determine user home cache : /usr/sap/<SID>/SYS/global
skyvva_v2.3.6/SKYVVA/com.skyvva.xml.RestIntegrationV3TransHandler.6: (getNewSalesforceContainerPooling) from .../SKYVVA_SalesforceContainer_CC_<short-hash>.ser
skyvva_v2.3.6/SKYVVA/com.skyvva.xml.RestIntegrationV3TransHandler.7: (getNewSalesforceContainerPooling) Pick up new session id from Salesforce    ← first call only
skyvva_v2.3.6/SKYVVA/com.skyvva.xml.RestIntegrationV3TransHandler.7: (getNewSalesforceContainerPooling) Session Id from Cache <session-id>        ← subsequent calls
skyvva_v2.3.6/SKYVVA/...RestIntegrationV3TransLogic.2: End transformation
skyvva_v2.3.6/SKYVVA/...RestIntegrationV3.13: End session handling

Three lines to check specifically:

1. Begin session handling (SKYVVA version 2.3.6) — confirms the deployed module is v2.3.6. If you see an older version, the SDA was not redeployed correctly.
2. OAuth2Flow: Client-Credentials in the channel parameter dump — confirms the channel was read with the right flow. If you see Username-Password (or no OAuth2Flow line), the parameter is missing or misspelled.
3. Pick up new session id from Salesforce on the first message; Session Id from Cache on every subsequent message. This is the normal pattern — the first call obtains the OAuth token, subsequent calls reuse it.

OAuth2Flow=Client-Credentials: SforceUsername and pwdSforceLoginPassword are ignored. Configure the Run-As user in the Connected App's OAuth Policies instead.

This is informational only — the message processes normally.

Troubleshooting

OAuth2Flow=Client-Credentials requires the following channel parameters but they are missing or blank: ...

The channel is missing one of AuthorizationServerURL, ConsumerKey, or ConsumerSecret. The error names the missing parameter — fix the channel configuration and re-send the message. This check runs before the OAuth call so misconfiguration fails fast with a clear cause instead of an opaque Salesforce error.

Unsupported OAuth2Flow value '<value>'. Expected 'Username-Password' or 'Client-Credentials'.

The flow value was typed incorrectly (for example Cleint-Credentials, client_credentials, CC). The accepted values are exactly Username-Password and Client-Credentials — case-insensitive but no fuzzy matching. Correct the channel parameter.

Salesforce OAuth2 Client-Credentials error: invalid_client - <description>

Salesforce rejected the token request. The <description> from Salesforce names the cause — typically one of:

• The External Client App is not enabled for the Client-Credentials flow.
• ConsumerKey or ConsumerSecret were copied incorrectly.
• The Run-As user assigned to the External Client App is inactive or locked.
• The External Client policy does not permit the calling IP or domain.

Salesforce OAuth2 Client-Credentials response missing access_token

Salesforce returned a token response without an access_token field. Indicates a Salesforce-side issue (the External Client App's OAuth Policies are misconfigured, or the userinfo endpoint is unreachable). Inspect the full Salesforce response in the audit log and consult Salesforce documentation.

Audit log shows INVALID_SESSION_ID detected. Renewing Salesforce session and retrying the API call once.

This is not an error. The module detected that the cached session was invalidated by Salesforce (typically because an admin ended the session, or the session timed out), and is automatically renewing it. The next line should show the renewal succeeding and the original API call retrying. If the retry also fails with INVALID_SESSION_ID, the module gives up with Session invalid even after renewal — verify that the External Client App is still active in Salesforce.

After upgrading from an older version, the first message uses a stale cached session

If the session cache file under SessionGlobalFilePath was written by an older module version, delete it and let v2.3.6 write a fresh one:

rm /usr/sap/<SID>/SYS/global/SKYVVA_SalesforceContainer_*.ser

The next message creates a new cache file using the v2.3.6-format key (which includes OAuth2Flow + ConsumerKey + USERNAME + PASSWORD + TOKEN so different flows and Connected Apps isolate cache slots).

Related articles

• How to Setup the SKYVVA Module Parameters in SAP PI/PO with V3? — base channel setup, prerequisite for this article.
• How to check the SKYVVA Java module version which is deployed in SAP PI/PO — confirms the running version after deploy.