This is the early access documentation preview for Custom Views. This documentation might not be in sync with our official documentation.
FAQs
Frequently Asked Questions about commercetools Composable Commerce
Haven't found your question? Check questions tagged commercetools on StackOverflow, ask a missing question there or contact the support team.
Where can I see my online shop?
commercetools Composable Commerce provides the backend of commerce applications through an HTTP API. It allows you to build whatever application you need, from 'classic' online shops to mobile applications, marketplaces, etc. We leave the implementation and hosting of your online shop to you.
The commercetools Frontend Store Launchpad for B2C was designed to showcase the features and functionality of Composable Commerce and Frontend. You can use the Store Launchpad for B2C as a starting point for developing your B2C commerce frontend.
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?
Search:
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 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:
- Customer Sign In (Authenticate Customer) operation
- Customer Sign Up (Create Customer) operation
- Get Cart by Customer ID operation.
How does Staging and Publishing / Push to Production of Product Data work in commercetools Composable Commerce?
In commercetools Composable Commerce, 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 Composable Commerce, 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 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 Composable Commerce, 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.
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.