Reference · built on requestConnectorCommerce & orders

SAP Commerce Cloud

Orders, carts, customers, product stock, and return requests from SAP Commerce Cloud through the OCC REST API and webhooks.

Request accessPricing ↗

About

SAP Commerce Cloud, formerly hybris, is an enterprise commerce platform for B2C and B2B storefronts. Its Omni Commerce Connect (OCC) REST API, the Commerce Webservices v2 under /occ/v2, exposes each base site's carts, orders, users, products, stock, and stores. The Integration API module adds OData Integration Objects and webhooks that fire when an item of a chosen type is saved or deleted.

Through Fibric, an operator reads orders and stock per base site, then proposes a cancellation request, a return request, or a stock check for a store. You approve. The connector calls OCC once and leaves a record: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from SAP Commerce Cloud and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders per base site through GET /{baseSiteId}/orders/{code} and a user's order history through GET /{baseSiteId}/users/{userId}/orders
  • Carts through GET /{baseSiteId}/users/{userId}/carts, including the current cart
  • Product stock through GET /{baseSiteId}/products/{productCode}/stock and per store through /stock/{storeName}
  • Return requests through GET /{baseSiteId}/users/{userId}/orderReturns and by returnRequestCode
  • Webhook notifications from the webhookservices extension when an Integration Object's root item is saved or deleted, with CloudEvents ce-type and ce-subject headers
  • Stores and their locations through GET /{baseSiteId}/stores

Proposed actions

  • Target capability: propose an order cancellation request through POST /{baseSiteId}/users/{userId}/orders/{code}/cancellation
  • Target capability: propose a return request through POST /{baseSiteId}/users/{userId}/orderReturns for selected order entries

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Cancel while cancellation is still possible

    A cancellation request comes in from support. The operator reads the order by code, checks its status and entries, and proposes POST .../orders/{code}/cancellation for the entries in question. You approve.

    With Cancellation Window

  • Triage return requests

    The operator reads new orderReturns per user, groups them by reason and product, and proposes which to approve, which to inspect, and which need a person, with the order record attached.

    With Returns Triage

  • Watch stock before it goes to zero

    For products in open carts and recent orders, the operator reads /products/{productCode}/stock per store and flags where demand exceeds what is on hand.

    With Oversell Watch

  • Hold suspect orders

    A webhook fires when an Order item is saved. The operator reads the order through OCC, checks totals and delivery details against your rules, and flags orders to review before fulfilment.

    With Order Risk

Requirements

  • An SAP Commerce Cloud instance with the Commerce Webservices (OCC v2) extension deployed and the base site ids you want to read
  • An OAuth client defined in Backoffice under System > OAuth, with client_credentials enabled and ROLE_CLIENT or ROLE_TRUSTED_CLIENT as the configuration requires
  • For push events, the Integration API extensions (integrationservices, outboundservices, webhookservices) installed, plus an Integration Object and a Consumed Destination per webhook
  • Network reach from Fibric to the OCC endpoint and from the instance to Fibric's webhook destination
Authentication
An OAuth 2.0 token from the platform's authorization server, using the client_credentials flow for a client with ROLE_CLIENT or ROLE_TRUSTED_CLIENT, or the password flow for a customer or customer manager.

Limits

  • Every OCC call names a base site, and order history is read per user id, so a full order sweep is assembled site by site.
  • Webhooks fire on save or delete of an Integration Object's root type. Each cluster node sends its own events; ce-subject may carry personal data.
  • The cancellation and orderReturns endpoints submit requests. Refunds and restocking follow the instance's own order management setup, not this connector.
  • Endpoint availability differs by release and installed add-ons; this listing follows the 2205 Commerce Webservices reference.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request SAP Commerce Cloud ↗

Questions and answers

Which OAuth flows does OCC accept?
Two are defined in the Commerce Webservices v2 reference: a password flow and a client credentials flow. Clients need ROLE_CLIENT or ROLE_TRUSTED_CLIENT; customers authenticated by password carry CUSTOMERGROUP or CUSTOMERMANAGERGROUP roles. OAuth clients and tokens are managed in Backoffice.
How do webhooks work in SAP Commerce?
The webhookservices extension sends a notification to a Consumed Destination when the root item of an Integration Object is saved or deleted. Headers follow the binary CloudEvents form: ce-source, ce-id, ce-specversion, ce-type, ce-subject, and optionally ce-time. Failed sends can be resent under at-least-once delivery.
Where does the API reference live?
The Commerce Webservices reference on the SAP Help Portal documents the /occ/v2 paths per release. The listing on the SAP Business Accelerator Hub requires an SAP account to view. Add-ons such as consignment tracking and customer coupons add further OCC paths.
Ask about SAP Commerce Cloud

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with SAP Commerce Cloud through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy