2022
Yearly archive of past Commerce Layer changelog entries.
Last updated
Was this helpful?
Yearly archive of past Commerce Layer changelog entries.
Last updated
Was this helpful?
Our revamped JS Drop-in library is out (the old one is now deprecated and will be no longer maintained). The new JS Drop-in lets can implement our commerce web components (price, availability, add-to-cart button, shopping cart, and checkout link), which can operate as framework-agnostic and customizable micro frontends, into any HTML webpage.
To learn more and see our micro frontends in action, explore the interactive documentation and read our blog and see our micro frontends in action.
We've released the first version of our My account application which provides a customer account experience that enables customers to manage their order and address information. In future releases, we will include customer waller and return management as well. As with all of our applications, a hosted version is available to use out-of-the-box, or the open-source repository can be forked and hosted on your end for any customizations you want to implement.
To learn more read our blog here.
v2.0.0 ⚠️Be advised that we introduced potential breaking changes ⚠️ by updating the way the Demo store manages locales and supported language. So far, locales were generated by combining all countries with all languages. Starting from v2.0.0 you need to specify a list of supported languages for each country. This both gives you more granular control of the country/language setup and helps reduce the demo store build times.
On top of that, now swatches can manage image URLs and base64 encoded images. We also added French translations.
The first release of our new Dashboard is live. Feel free to explore this completely redesigned, developer-centric admin console that now makes it much easier for Commerce Layer users to manage their store's set-up and applications. Any feedback is appreciated.
To learn more, read our blog here and get a comprehensive overview of all the major changes.
v2.0.0Starting from v2.0.0 our hosted cart is based on Vite. Next.js has been removed and the routing is now handled by the minimalist-friendly wouter. These changes bring a big benefit in terms of bundle size which now is almost half the size of the previously compiled output. On top of that, we switched the package manager from yarn to pnpm.
v4.0.0 ⚠️React components v4.0.0 now support React 18. With this major release, we also added to our set of components a subset you can leverage to build a dedicated account area for registered users — here you can find some example pages.
To boot, be advised that we introduced potential breaking changes ⚠️ by removing some old components (ItemContainer, VariantContainer, VariantSelector, QuantitySelector, SkuOptionsContainer, SkuOption, and SkuOptionInput) — please refer to this folder on the public repository for the updated list of available components.
We’ve released our Metrics API, which now enables Commerce Layer clients to extract, organize and analyze any kind of data from their organization’s order, return, or cart history. It’s possible to:
Retrieve store data via four different queries (breakdown, date breakdown, stats, and search).
Filter these queries based on dates or any other available field.
Queries can be used to get instant insight based on calculation parameters and object attributes, such as calculating the return rate of an SKU within a specific market or within a certain date range. The Metrics API can also power any kind of customized reporting system or data visualization dashboard, making it much simpler to create reporting by pre-calculating the data before sending it.
As a brand new API, the Metrics API is available to all Commerce Layer customers as part of an early access beta. Once the beta period has ended, the Metrics API will only be available to customers on our Enterprise plan.
To learn more, read our blog here.
It’s now possible to configure Microstore URLs from a single command using our Microstore CLI plugin. This makes Microstore configuration more agile and simple by automating it instead of manually stringing together the URL. To use the plugin, you can install it by running commercelayer plugins:install microstore. To learn more about the plugin commands and options, please refer to the open-source GitHub repo README.
v2.0.0Starting from v2.0.0 the hosted checkout won't require Node.js hosting anymore, since now it is a single-page application (SPA). On top of that, we changed the package manager from yarn to pnpm. Instead of building the project, now it's required to export it using the command pnpm run export. You can run it in a local environment using pnpm run serve.
We also set up the whole test suite to run on CircleCI so as to give us a boost of confidence for each new release.
v1.10.0Hosted checkout v1.10.0 now supports new payment methods (Klarna and PayPal, in addition to the already available credit card one) on the Adyen gateway. You can manage them by country, on your Adyen account where you can directly sort the available payment methods. The Adyen Drop-in library will then replicate the sorting on our hosted checkout. Please note that setting up third-party access on your PayPal account is mandatory for the correct operation of the integration.
v1.10.0 also comes with an improved user experience regarding the Payment step of the checkout flow: now if there is only one payment method available in the market it will be automatically selected.
v3.15.0React components v3.15.0 now supports Klarna and PayPal payments via the Adyen gateway (in addition to the credit card one, which was already available).
We’ve released our Demo Store as an open-source project. This Demo Store is a completely static ecommerce solution (with SSR capability) powered by Commerce Layer. The store is full-featured and fully operational, with no third-party services required (e.g. everything related to content is stored as JSON files). You can easily tailor your own with different levels of customization.
The Demo Store project consists of two repositories that you can leverage to build your own store:
demo-store — This is a GitHub template. If you're happy with the features and the look and feel of the Commerce Layer Demo Store you can just use this template without having to care about the whole source code. You'll be free to focus on your data and you'll get free updates with almost no risk.
demo-store-core — This repository contains the source code. If you need to fully customize your store (behavior, UI, UX, etc.) you just have to fork this repo and create your own (this is also the way to contribute).
You can deploy the Demo Store wherever you prefer, both using SSG and SSR.
To learn more, read our blog here.
We’ve released our Microstore app for all Commerce Layer accounts, which enables you to configure self-contained stores directly through a URL. To do that through the hosted version of the app:
Determine how long you want the microstore to stay up by setting the expiry length of the sales channel you wish to use.
Get an access token for that sales channel putting in scope the market you wish to sell from.
Get the ID of the SKU list that contains the products you wish to sell.
Use them to compose the microstore URL like so:
It’s also possible to fork your own version of the app, as explained in the documentation of the GitHub open-source repo.
To learn more, read our blog here.
The Cart app is an open-source, React-based application that provides you with a production-ready shopping cart powered by Commerce Layer APIs. You can fork the repository and deploy it to any hosting service or use it as a reference application to build your own. A hosted version is also available and it's automatically enabled for all Commerce Layer accounts — you just need an order ID and a valid sales channel access token to compose the related cart URL with the following format:
The cart can also be embedded in your application or website by loading the hosted URL in an inline frame.
We introduced a new default inventory model strategy called no split. This strategy considers just one stock location (the primary one or the first in scope) when checking the inventory for availability and always creates just one shipment, no matter if the SKUs in the order belong to different shipping categories. The aim is to simplify the default rebuild shipments process and enable better performance. If this strategy is too basic for your business model, you can still pick another that better suits your needs: split shipments, ship from primary, ship from first available (or primary).
It is also now possible to enable/disable shipping methods and payment methods directly via API. You just need to pass the _enable or _disable trigger attributes in the payload when patching the resources.
Now you can specify a custom lifetime for the access tokens you get when authenticating your Commerce Layer applications (sales channels, integrations, webapps). This can be done at the app level on the admin dashboard when you create/update each application. The token lifetime value must be expressed in seconds and fall within a minimum of 2 hours and a maximum of 1 year.
Commerce Layer now supports tiered pricing strategies based on volume. These tiers can be used to enable specialized pricing when customers order in quantity, like offering a unit discount when a customer orders 10 of an SKU instead of 1.
We’ve introduced two new resources — price tiers and price volume tiers — enabling you to create up to 5 tiers for each price. The price of the associated SKU will then be set by the tier the total quantity of items falls within. Price tiers can be imported together with their related prices.
The shipping methods availability management has been improved:
The relationships with the shipping zone and the shipping category has been relaxed (they're now both optional when creating a shipping method).
A new optional relationship with a stock location has been added so that the shipping method will only be available if the items are shipped from that specific stock location.
A new optional weight-based constraint on the shipping method availability has been added. Now you can define a minimum and/or a maximum weight threshold and make the shipping method available only if the total weight of the items in the shipment falls within the threshold.
The shipping methods cost management has also been updated. Now you can select one of two schemes:
Flat — the shipping method has a fixed cost.
Weight-tiered — the shipping method's price is tiered based on the total weight of the items in the shipment. Two new resources have been introduced (shipping method tiers and shipping weight tiers) so that you can create up to 5 price tiers for each shipping method.
A new events endpoint has been exposed (which can be used to improve webhooks management and monitoring). Events can be included when fetching the resources that support them in order to inspect each recorded action.
Order status changes are now idempotent. This means order and payment statuses stay consistent with multiple updates, which can limit the effect of transaction errors. For example, it's now possible to place or cancel an order more than once without worrying about duplicated transactions (or other unintended effects). Because of this, order status-related actions such as webhook events and stock item updates are only executed once.
Adyen gateway authorizations via 3DS now generate just one transaction.
Free gift and fixed price promotions can now apply to bundles (as long as they share the same SKU list). Both can now combine with other promotion types (but cannot overlap with each other or with other promotions of the same type). Two new relationships have also been added to the order object (available_free_skus and available_free_bundles), which is useful when presenting the customer with a list of possible free gifts during checkout.
v1.7.0Hosted checkout v1.7.0 now supports Checkout.com out-of-the-box (in addition to all other payment gateway integrations). A new error handling process for out-of-stock and no shipping zone errors is now available.
v3.11.1React components v3.11.1 comes with valuable improvements regarding the stock transfer components. Now developers can customize stock transfers alongside line items in a rapid and efficient way.
A new OAuth endpoint has been exposed. You can now unpack the JWT token information by sending a GET request to oauth/tokeninfo. The response will contain some useful info such as the application type, the owner, and the associated roles, permissions, and scopes.
AvaTax is a full-service engine for calculating transactional taxes, including sales, use, VAT, and many other tax types. If you're using Avalara as the tax calculator associated with one (or more) of your markets, you can now register tax computation on their systems (SalesInvoice). This is useful for tax returns in the US.
v3.10.0React components v3.10.0 now supports Klarna and Checkout.com out-of-the-box (in addition to all the other payment gateway integrations).
Commerce Layer API now supports Checkout.com out-of-the-box (in addition to all the other payment gateway integrations). Bundles and SKU options have been added to the list of importable resources.
v1.5.0Hosted checkout v1.5.0 features robust improvements on how the application state is managed, which translates into a speed boost and offers a way to hook on each user action. The checkout flow has also been streamlined by introducing auto-selection of the shipping method when the shipment only has a single shipping method available.
In order to prevent errors in some edge cases where an order can be placed after the authorization was created by the Stripe webhook, a large set of optimizations has been implemented on our Stripe integration. Among them:
A control on order placement to check if the payment has been authorized has been introduced.
Previously created Stripe's payment sources are now nullified in case of order edit/refresh. The related authorizations are voided.
The _nullify_payment_source trigger attribute has been added to the order object in case you want to force the payment source nullification.
On top of that, a payment source nullification automation has been introduced for all intent-based payments (e.g. Stripe, Klarna, PayPal).
Our PayPal integration has been updated and now uses the most recent PayPal V2 libraries (no changes to the developer experience and integration functionalities).
Commerce Layer API now supports Klarna out-of-the-box (in addition to all the other payment gateway integrations).
v1.1.0Hosted checkout v1.1.0 now supports bundles, showing them in the order summary as a single line item and unpacking them in terms of single SKUs inside each shipment.
We’ve introduced a new API endpoint that makes it much more straightforward to clean out old data and maintain a clean store. enable you to remove entire sets of resources (e.g. the ones that you're not using anymore) and their relationships based on certain criteria (). includes SKUs, prices, stock items, promotions, gift cards, and more. For performance reasons and in order to preserve data integrity the process is subject to some and .
It’s now possible to disable/enable resources. If there are markets that are no longer in use, you can disable them (and re-enable them for any reason). This offers more flexibility for clients on our Free and Growth plans, as disabled markets do not count against the market limit. If you've reached your plan's limit in terms of the number of markets, make sure to disable one of the active markets before enabling a new one.
We also aggregated the attributes you can skip when performing an by introducing the dry data mode. Now you just need to send the dry_data attribute when creating the export to automatically .
We’ve changed the ability to manage SKU lists from the (which now have read permission only) to . Now, you can optionally associate an with a . To create and update an SKU list, you need to authenticate using the .
Now you can your organization's resources directly . The exported data can be saved as JSON (default) or CSV data. You can specify for each resource the relationships you want to include (among the supported ones), apply some filters to narrow the exported data, and decide to eventually skip redundant attributes. The output is stored on an external service you can access via the export attachment_url attribute, available upon export completion.
Some similar changes have been introduced to our functionality: now you can specify inputs data as a JSON (default) or CSV file, which is stored on an external service accessible via the import attachment_url attribute as well. Imports of multi-nested resources are also now supported (e.g. line_items.line_item_options for orders).
All of the output data you get from exports is ready to be used as inputs for the (this is particularly convenient when migrating test data to your live ).