FAQs

Frequently Asked Questions about the commercetools platform

Haven’t found your question? Check questions tagged commercetools on StackOverflow, ask a missing question there or contact our support team.

Where can I see my online shop?

The commercetools platform provides the backend of E-Commerce applications through an HTTP API. Since the platform allows you to build whatever application you need, from ‘classic’ online shops to mobile applications, market places and so on, we leave the implementation and hosting of your online shop to you.
To help you with building your online shop we provide some template shops you can use as examples. Please find them among other useful open source software, such as SDKs and command line tools for data import, export and synchronization, on our Developer Tools page.

What do I need the slug for?

Slugs are human-readable identifiers usually used in online shops as deep-link URL to the related product. Slugs provide a “nicer” link to the products compared to randomly generated strings as long as they are unique across the project.

What is the difference between search and query?

The Product Projection Search endpoint is the most performant choice for product lookup since it allows quick responses due to Elastic Search support. In case Reference Expansion is desired one of the query options below needs to be applied.

Product Projections query:

The Query Product Projections method requires the backend to go through the product database in order to check the products against the query predicates. Thus, the query requested from a shop-front-end can take much longer compared to a search request. The amount of data to be submitted is lower compared to the ‘product query’ method below. Reference Expansion is supported by this method.

Product query:

The Query Products method is the preferred option for shop-backends since the representations for the staged as well as the current Product Projection are returned. Reference Expansion is supported by this method.

How to make anonymous carts persistent?

Anonymous cart is by default persistent until it gets merged (upon customer’s sign in or sign up) with customer’s cart. You need to store the ID of the anonymous Cart on your end. Fetch the particular cart via Get Cart by ID operation.

How to make customer’s carts persistent?

The customer’s cart is persistent by default for an unlimited time. Customer’s cart can be retrieved via:

How does Staging and Publishing / Push to Production of Product Data work in the commercetools platform?

In the commercetools platform, you always have 2 versions of the Product Data - current and staged. You can use this to change the product data without changing the running Production website, and preview the changes before you make them live. In the commercetools platform, no data is actually copied back and forth between different instances or databases, but only between the current and staged field of the ProductCatalogData. This means that you can run a staging site for preview purpose and your production site from one single commercetools platform project. It is also best practice to only make changes in the staged version of your product data.

All changes are usually made in the staged version of the data to not impact a running website, and then published using the Publish API Call. Both versions are present in the Product resource within the ProductCatalogData. If you use Product Search API and the Product Projection Resource, you only get either the staged or the current version, depending on whether you set the staged parameter to true or false (default = false). You can learn whether your product has been published and has staged changes by observing the flags published and hasStagedChanges that are part of the ProductCatalogData field.

What is the “Master Variant” and what can I use it for?

In the commercetools platform, the ProductVariant is supposed to be the only sellable entity, but not the abstract Product itself. Therefore, the first role of the master variant is to ensure that the product has at least 1 variant that can be purchased. This means that even a simple product always has one, and your shop implementation logic does not have to deal with any polymorphism where you have to consider a Product and a ProductVariant to be added to a cart.

Furthermore, in our default shop implementation such as Sunrise, we use the master variant as our preferred variant (i.e. with best selling color or image) on product overview, search or product detail page, if no other parameters to determine the suitable variant are given. So you can control which color and size for instance is shown and selected by default, if no other criteria to select a variant to display are given.

The variants have an implicit order that is governed by the variant’s id field. The master variant always has id set to 1, making it the first in the order of variants.

In the Merchant Center, attributes with the SameForAll constraint are editable as “Product Attributes”. Editing them sets the attributes on all variants. When updating product data through the HTTP API, you can use the setAttributesInAllVariants Update Action.