Frequently Asked Questions about the commercetools platform
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 the SDK and Tools page.
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.
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.
The Query Product Projections method requires the backend to go through the product database 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.
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.
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.
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
false (default =
You can learn whether your product has been published and has staged changes by observing the flags
hasStagedChanges that are part of the ProductCatalogData field.
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 the default shop implementation such as Sunrise, we use the master variant as the preferred variant (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. 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.