The Salesforce Commerce API relies on a central infrastructure for routing and serving the API responses. This infrastructure is separate from the standard B2C Commerce Cloud POD infrastructure to provide robust scaling and performance.

Current region deployments:

  • US East
  • EMEA (Frankfurt)
  • APAC (Sydney)
  • Japan

All B2C Commerce Cloud instances can access the Salesforce Commerce API. As part of the routing that occurs with a given short code, the incoming API request is routed to the closest deployed region based on the POD location for your realm. When new regions are added, the routing of existing short codes automatically occurs.

Caching of Salesforce Commerce API responses improves the performance of your commerce application. Caching frequently requested data in the top layers of the application enables the system to respond quickly, avoiding the need to access the server or database.

Our caching approach involves two main layers:

  1. Client-side caching: the front-end application layer you develop with our Node.js SDK or by with any other technology that uses our APIs.
  2. Server-side caching: the backend layer that includes our API middleware and service implementations.

In the Salesforce Commerce shopper APIs, GET requests provide cache headers in their responses. These headers indicate whether a resource is private or public (public resources are eligible for caching). For example: Cache-Control: public.

You can check the value of this response header when you implement your own headless commerce app. For more details, see B2C Headless Implementation Guide.

The information in the resource header is used by the Commerce SDK to create caches for all responses with a public cache header.

The caching capabilities of the Commerce SDK are implemented using the Web API standard Cache API. The API is exported as a TypeScript interface from the SDK core package.

You can configure caching by instantiating a cache manager and then passing it to an instance of one of the SDK clients as an option.

At this time, in-memory caching and Redis caching are available in the SDK. In-memory caching is enabled by default. You can completely disable caching for a client by setting cacheManager to null. If you want to implement your own caching solution, you can do so by implementing the ICacheManager interface. The Commerce SDK is open-source, so it has both of the existing implementations for reference.

The storage and use of responses is governed by standard Cache-Control headers.

In the Salesforce Commerce API (as of September 2020) shopper API GET requests have their service implementation in an assigned B2C Commerce system. As a consequence, the standard B2C Commerce caching for all GET requests in the OCAPI Shop API applies to the shopper APIs (provided the underlying Shop API resources are marked as cacheable).

The current standard caching time value in B2C Commerce is 60 seconds.

Currently it is not possible for you to control server-side cache times on B2C Commerce. All known approaches from the OCAPI Shop API (for example, setting cache times in the OCAPI settings) don’t apply to the Salesforce Commerce API.