Skip to Main Content

Jul 29, 2020 | 7 minute read

How does composable commerce support functionality for cross-sell, up-sell and substitutions?

written by Scott Johnstone

Regardless of what you use for your backend, all of the various front-end user interfaced will require coding. However, the more important factor to take into account is how tightly coupled or controlled will your front-ends be to the backend. If you are not using composable commerce as a service, it will like very tightly control and couple and will limit your capabilities or make implementation more difficult.

What does that mean?

Platform constraints will be the biggest cost of most traditional implementation. Whether you use a SaaS based or on-premise version of a legacy platform, minor changes such as adding a cross-sell relationship to your products catalog, as well as larger changes like extending customer data, will require custom development and database changes. These types of customizations increase your technical debt and slow future progress.

However, for a Composable Commerce architecture, to implement cross-sell, substitutions or other product relationships, all that is required is a simple API call to add the relationship. Similarly, for more complex customizations, it is just a few more API calls to configure the data structure changes.

Cross-Sell Example Request

Elastic Path Commerce Cloud is the first composable commerce platform. To implement cross-sell from a brand-new instance of an Elastic Path store, there are 3 steps.

Step 1: Enable the products extended data container

The response of this request contains the ID for this container. That ID will be used in Step 2.

Step 2: Add the Cross-Sell relationship to the products “flow” (“flow” is the is the name of the tool used to create the container)

Once you have the container created, the next step is to add the field. Below is the payload used to create the Cross Sell field. They key takeaways from this section is to ensure:

  • “field type” is set to “relationship”
  • the validation rules state “type” is set to “one-to-many” relationship
  • the validation rules state “to” is set to the “product”

The rest of the fields are fairly self-explanatory. So, in this instance you are relating products to other products. These types of relationships can be leveraged for any number of use cases.

Step 3: Start adding products to the relationship

Now that your Cross-sell relationship field is in place, you simply need to start adding products to the field. This is done by calling the relationship end-point created when you created the cross-sell field.

POST the array of product IDs to the following endpoint where {{product_id}} equals the product you are updating.{{product_id}}/relationships/cross_sell_id

The source of these product references can come from your own merchandising team, 3rd party tools or analytics or wherever you choose.

Include the data when you want it

Once the relationship is set it can be retrieved with the normal products API call. To retrieve the cross sell products, simply add “include=cross_sell_ids” to the query string of the products endpoint to include product information for each of the related products in a single request to the API.


The response: The figure below displays the response that includes the cross_sell products. The response contains two different relationship types. The first is “main_image” which is a built-in relationship between the product and its primary image. The second is the one we just created and populated.

In the “data” array, the first object is the product we are requesting. Toward the end of the response is a second object named “included” where the details of the products listed above in the relationships object “cross_sell_id” which is the list of product_ids that are cross sell items. These are sample products made up of data from placeholder content sites from around the web. My favorite is for generating creative paragraphs of text for descriptions. But, I digress.

This is solely one example of adding a cross sell relationship with Elastic Path. If you want to add relationship like “Substitutions”, all you will need to do is repeat steps 2 and 3. The same thing goes for adding an “Up-Sell” relationship as well. For each additional field, you make a single API call to the platform.

To extend other objects such as Customers or Orders or Carts, the pattern is the same. Step 1, create the container, step 2 add the fields and step 3, add the data. No other platform is easier to extend the data or APIs.

Why is this so important?

The resulting changes are immediate. They become part of the API and do not require any coding to create. Objects can be related to themselves or to other objects. Another common example is a customer wishlist. To create a customer “wishlist”, you would create a relationship field on the Customer object that is a one-to-many relationship to products. The options this approach creates is almost endless.

Feature or Capability

If you asked me if “Wishlists” were an “Out-Of-The-Box” feature of Elastic Path we would say “No”. However, Elastic Path is more than capable of simply implementing wishlists or other types of relationship functions with a few API calls.

Inversely, think about how many features that come as an out-of-the-box feature in other platforms that you do not use but still have to keep the code around. By keeping the platform clean and simple, and using API calls for only the functionality you desire, we enable extension without complications.

If you have other questions or challenges with your platform and want to consider moving to the future with composable commerce, please get in touch with us. We would be happy to talk through your challenges and use cases to see how we might help you.