First look at Sitecore OrderCloud

Sitecore acquired four51.io, a company known for its product called OrderCloud, a next-generation, B2B-focused commerce platform based on MACH architecture.

Sitecore rebranded this into Sitecore OrderCloud.

Since it’s a SaaS tool, you can set up a free account within minutes: simply register on https://ordercloud.io to get your sandbox environment (no credit card needed)


The getting started guide gives you a good understanding of the basic concepts.

Here are my first impressions of it after browsing through the playground environment and the API reference.

What’s an OrderCloud?

The Sitecore Acquisition of Boxever and Four51 FAQ page frames it as

  1. Microservices-based, so individual pieces of business functionality can be independently developed, deployed, and managed.

  2. API-first, with all functionality exposed through an API to allow simple, seamless integration.

  3. Cloud-native SaaS to leverage the full capabilities of the cloud, including elastic scaling and automatic upgrades.

  4. Headless, where the front-end user experience is completely decoupled from the back-end logic, allowing for complete design freedom to create the user interface and connect to other channels and devices.

It comes with the following core concepts:

  • Sellers
  • Buyers
  • Suppliers
  • Product Catalogs
  • Orders and Fulfillment

Instances of all of these are grouped in a marketplace.


OrderCloud allows you to set up multiple marketplaces under the same account. Marketplaces are completely separated from each other (multi-tenant principle).

Postman friendly

OrderCloud is basically an API in the cloud that you call (GET / POST / … over HTTPS, SDKs available for multiple languages) to set up and run your store site.

The API is exposed with OpenApi, a standard, language-agnostic interface to RESTful APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection maintained by swagger.

Simply import https://api.ordercloud.io/v1/openapi/v3 into Postman to get a collection with all available routes:

The core concepts and their relations are easily managed using the standard GET / POST / PUT / … HTTP verbs.


See the API reference to get a feeling of what’s possible.

So what about the back-end?

In a headless scenario, the front-end is something you build yourself of course.


But what about the back-end? Some products offer you a straightforward user interface where you can see and edit the core concepts (e.g. change values), but not order cloud.


The only back-end you have in the cloud is developer-oriented. Basically, it’s PostMan in your browser:

In its feature guide, Sitecore mentions HeadStart as (among other things) a tool for commerce management (basically, a back-end). Unfortunately, the only info I found on it is an example implementation on GitHub (https://github.com/ordercloud-api/headstart).


It illustrates to possibilities to do your own implementation, but -in my opinion-, it’s not something you can convince a customer with as an out-of-the-box solution.


The screenshots in the guide look totally different from the demo environment, so more to come on this I hope.

It’s all about me

An interesting concept in OrderCloud that will certainly speed up your front-end store implementation in building up context around your current shopper, simply called me. The idea is that, in OrderCloud, you

  • model a buyer organization. This defines the catalog, products, prices, …. This can range from a straightforward (single buyer/seller) to complex (lots of different buyers each having their specific sellers, prices, rules, …) setups.
  • assign one or more buyer users to a buyer organization. Basically, this is somebody who can buy the configured catalog/product/prices. These can be known/registered users or default anonymous users.

On your front-end store implementation, you

  • identify the current shopper using an external login or as anonymous
  • get an OAuth/token for this shopper from OrderCloud (identified as a buyer user)

With this token you call the /me endpoint to get back context-specific information for this user:

  • /me/addresses
  • /me/catalogs
  • /me/products
  • /me/orders
  • /me/promotions

The endpoints support all kinds of operations: GET by ID, filter by the property, text search, …

In my opinion, this is where the power of OrderCloud lays: the core concepts are very flexible to set up in terms of variations and dependencies.

This allows you to set up a back-end integration process, responsible for syncing data from various back-end systems into the OrderCloud format. Enforcing the logic business requires you to.

On the front-end, all of this complexity is abstracted away behind the authentication token and uniform endpoints.


Making it very easy to offer a personalized shopping experience (in terms of products, prices, …) for your customers.


Comments