SAP Commerce User Management API Guide

Auth method: OAuth 2.0 (client_credentials and password grant types supported via SAP Commerce OAuth server at /authorizationserver/oauth/token)

Setup steps

1. Register an OAuth client in SAP Commerce Backoffice under OAuth Clients (OAuthClientDetails).
2. Assign appropriate scopes (e.g., basic, extended) to the OAuth client.
3. For customer-facing flows, use the 'password' grant type with customer credentials; for server-to-server, use 'client_credentials'.
4. Obtain an access token via POST to /authorizationserver/oauth/token with client_id, client_secret, grant_type, and (if password grant) username/password.
5. Pass the Bearer token in the Authorization header for all OCC API requests.

Required scopes

Register a new customer

• Method: POST
• URL: /occ/v2/{baseSiteId}/users
• Watch out for: Requires a client_credentials token (not a customer token) for self-registration flows. The baseSiteId must match a configured base site.

Request example

POST /occ/v2/electronics/users
Authorization: Bearer {client_credentials_token}
Content-Type: application/json
{
  "firstName": "Jane",
  "lastName": "Doe",
  "uid": "jane.doe@example.com",
  "password": "Passw0rd!",
  "titleCode": "ms"
}

Response example

HTTP 201 Created
{
  "uid": "jane.doe@example.com",
  "customerId": "abc123guid",
  "firstName": "Jane",
  "lastName": "Doe",
  "displayUid": "jane.doe@example.com"
}

Get customer profile

• Method: GET
• URL: /occ/v2/{baseSiteId}/users/{userId}
• Watch out for: The userId in the path must match the authenticated user's uid unless the caller has admin privileges. Use 'current' as userId alias for the authenticated user.

Request example

GET /occ/v2/electronics/users/jane.doe@example.com
Authorization: Bearer {customer_token}

Response example

HTTP 200 OK
{
  "uid": "jane.doe@example.com",
  "firstName": "Jane",
  "lastName": "Doe",
  "currency": {"isocode": "USD"},
  "language": {"isocode": "en"}
}

Update customer profile

• Method: PUT
• URL: /occ/v2/{baseSiteId}/users/{userId}
• Watch out for: PUT replaces the full profile; omitting optional fields may reset them. PATCH is not supported on this endpoint in standard OCC v2.

Request example

PUT /occ/v2/electronics/users/jane.doe@example.com
Authorization: Bearer {customer_token}
Content-Type: application/json
{
  "firstName": "Jane",
  "lastName": "Smith",
  "titleCode": "ms"
}

Response example

HTTP 200 OK
{}

Change customer password

• Method: PUT
• URL: /occ/v2/{baseSiteId}/users/{userId}/password
• Watch out for: Requires the current password ('old' param). Admin password resets use a different Backoffice/ImpEx flow, not this endpoint.

Request example

PUT /occ/v2/electronics/users/jane.doe@example.com/password
Authorization: Bearer {customer_token}
Content-Type: application/x-www-form-urlencoded
old=OldPass1!&new=NewPass2!

Response example

HTTP 202 Accepted

Delete (close) customer account

• Method: DELETE
• URL: /occ/v2/{baseSiteId}/users/{userId}
• Watch out for: This closes/anonymizes the account (sets deactivationDate) rather than a hard delete, depending on GDPR anonymization configuration.

Request example

DELETE /occ/v2/electronics/users/jane.doe@example.com
Authorization: Bearer {customer_token}

Response example

HTTP 200 OK

List customer addresses

• Method: GET
• URL: /occ/v2/{baseSiteId}/users/{userId}/addresses
• Watch out for: Address IDs are system-generated GUIDs. The defaultAddress flag is set separately via PUT /addresses/{addressId}.

Request example

GET /occ/v2/electronics/users/jane.doe@example.com/addresses
Authorization: Bearer {customer_token}

Response example

HTTP 200 OK
{
  "addresses": [
    {"id": "addr1", "line1": "123 Main St", "town": "Austin", "country": {"isocode": "US"}}
  ]
}

Login (obtain customer token)

• Method: POST
• URL: /authorizationserver/oauth/token
• Watch out for: The OAuth client (client_id) must be pre-configured in SAP Commerce with the 'password' grant type allowed. Token expiry is configurable per OAuth client.

Request example

POST /authorizationserver/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=password&client_id=mobile_android
&client_secret=secret&username=jane.doe@example.com
&password=Passw0rd!

Response example

HTTP 200 OK
{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 43199,
  "scope": "basic openid"
}

Get B2B org customer list

• Method: GET
• URL: /occ/v2/{baseSiteId}/users/{userId}/orgCustomers
• Watch out for: Only available in B2B Commerce (powertools/B2B base sites). Requires the caller to have b2badmingroup or b2bmanagergroup role.

Request example

GET /occ/v2/powertools/users/admin@example.com/orgCustomers
Authorization: Bearer {b2b_admin_token}

Response example

HTTP 200 OK
{
  "orgCustomers": [{"uid": "buyer@example.com", "roles": ["b2bcustomergroup"]}],
  "pagination": {"currentPage": 0, "pageSize": 20, "totalResults": 1}
}

• Rate limits: SAP Commerce Cloud does not publish fixed rate-limit tiers in official documentation. Rate limiting is configurable at the infrastructure/API gateway level (e.g., SAP API Management or customer-managed reverse proxy). No specific numeric limits are documented publicly.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: Rate limiting behavior depends on deployment configuration. SAP API Management can be layered in front of OCC to enforce quotas; specific limits are not documented in SAP Help Portal.

• Pagination method: offset

• Default page size: 20

• Max page size: 100

• Pagination pointer: currentPage / pageSize

• Webhooks available: No

• Webhook notes: SAP Commerce OCC REST API does not provide native outbound webhooks for user/customer lifecycle events. Event-driven integration is handled via SAP Commerce's internal event framework or SAP Integration Suite.

• Alternative event strategy: Use SAP Commerce's AfterSaveEvent / CustomerRegistrationEvent listeners (Java extension) or integrate with SAP Integration Suite (CPI) to publish events to external systems on user lifecycle changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (SAP Commerce Cloud public cloud; requires SSO prerequisite via SAP Identity Authentication Service)

• Endpoint: Provisioned via SAP Identity Authentication Service (IAS) SCIM 2.0 endpoint; not a direct OCC endpoint. Endpoint URL is tenant-specific: https://{tenant}.accounts.ondemand.com/scim/v2/

• Supported operations: Create User, Read User, Update User, Deactivate User, List Users

Limitations:

• SCIM provisioning targets SAP Identity Authentication Service (IAS), which then federates identity into SAP Commerce Cloud - not a direct Commerce OCC SCIM endpoint.
• SSO via SAP IAS is a prerequisite for SCIM-based provisioning.
• Available on Enterprise tier / SAP Commerce Cloud public cloud; not available for on-premise SAP Commerce installations without additional configuration.
• Group/role provisioning support depends on IAS and Commerce Cloud connector configuration.
• Okta and Microsoft Entra ID are supported IdPs for SCIM provisioning via IAS; Google Workspace and OneLogin are not listed as supported.

Three integration patterns cover the majority of production use cases.

First, self-service customer registration: obtain a client_credentials token, POST to /users to create the account, then exchange for a password grant token for all subsequent customer-scoped calls

the token type must switch between these two phases or registration will fail.

Second, SCIM-based provisioning from Okta or Entra ID: SCIM 2.0 is available on the Enterprise tier but targets SAP Identity Authentication Service (IAS) at https://{tenant}.accounts.ondemand.com/scim/v2/, not the OCC layer directly;

IAS then federates identity into Commerce Cloud, and the Commerce Cloud connector to IAS must be configured separately before provisioned users can authenticate.

Third, B2B org user management: creation and role assignment use a distinct endpoint set (/orgCustomers, /orgUnits, /orgUserGroups) that is only available on B2B-configured base sites

calling these endpoints against a B2C base site returns 403 or 404, and role values must exactly match configured B2B user group identifiers (b2bcustomergroup, b2bmanagergroup, etc.).

Self-service customer registration and profile retrieval

1. Obtain a client_credentials OAuth token using the storefront OAuth client credentials (POST /authorizationserver/oauth/token, grant_type=client_credentials).
2. POST /occ/v2/{baseSiteId}/users with firstName, lastName, uid (email), password, and titleCode to register the customer.
3. Obtain a customer-scoped password grant token using the new customer's credentials.
4. GET /occ/v2/{baseSiteId}/users/current with the customer token to retrieve the full profile.

Watch out for: Registration (POST /users) must use a client_credentials token, not a customer token. Switching to a password grant token is required for subsequent authenticated customer operations.

SCIM-based user provisioning from Okta to SAP Commerce Cloud

1. Ensure SAP Identity Authentication Service (IAS) is configured as the identity provider for the SAP Commerce Cloud tenant.
2. In SAP IAS admin console, enable SCIM 2.0 provisioning and note the tenant SCIM endpoint (https://{tenant}.accounts.ondemand.com/scim/v2/).
3. In Okta, add SAP Identity Authentication Service as a SCIM application using the IAS SCIM endpoint and a technical user credential.
4. Map Okta user profile attributes to SCIM attributes (userName → uid, name.givenName → firstName, etc.).
5. Assign users/groups in Okta to trigger SCIM provisioning to IAS, which federates the identity into SAP Commerce Cloud.
6. Verify user appears in SAP Commerce Backoffice under Customers.

Watch out for: SCIM provisions identities into IAS, not directly into SAP Commerce OCC. The Commerce Cloud connector to IAS must be configured separately. SSO must be active for the provisioned users to log in.

B2B org user creation and role assignment

1. Authenticate as a B2B admin user (b2badmingroup) using password grant OAuth token.
2. POST /occ/v2/{baseSiteId}/users/{adminUserId}/orgCustomers with the new B2B buyer's details (uid, firstName, lastName, roles).
3. Assign the user to an org unit via PUT /occ/v2/{baseSiteId}/users/{adminUserId}/orgUnits/{orgUnitId}/users/{newUserId}.
4. Verify the user's roles and unit membership via GET /occ/v2/{baseSiteId}/users/{newUserId}/orgCustomers.

Watch out for: B2B endpoints are only available on B2B-configured base sites (e.g., powertools). Using these endpoints on a B2C base site returns 404 or 403. Role values must match configured B2B user groups (b2bcustomergroup, b2bmanagergroup, etc.).

Several behaviors diverge from standard REST API expectations and will cause silent failures if not accounted for. PUT /users/{userId} performs a full replacement - omitting optional fields resets them; PATCH is not supported on this endpoint in OCC v2.

DELETE /users/{userId} may anonymize rather than hard-delete the record depending on the gdprAnonymizeCustomer configuration flag, which means the uid may remain reserved and the deactivationDate field becomes the reliable signal for account state in an identity graph. Rate limiting is not documented at fixed numeric tiers;

limits are enforced at the infrastructure or SAP API Management layer and vary by deployment, so callers must implement adaptive retry logic rather than relying on published thresholds. Pagination uses offset-based currentPage/pageSize parameters with a default page size of 20 and a maximum of 100; there are no cursor or keyset options.

Finally, SCIM provisioning does not flow through OCC - there is no /scim/ path on the OCC base URL - so any integration that assumes direct SCIM-to-Commerce connectivity will fail at the routing layer.