Changelog
Commerce Layer changelog for software updates, new features, and general improvements.
We added a new entry to our set of external resources feature. Now you can override a shipping method cost with a price calculated externally by any (custom) service. You just need to set the shipping method's
scheme to external, provide the external_prices_url from where to fetch the related value, and make sure your external service response in case of success or error is compliant with the specifications.
Be advised that we introduced a potential breaking change ⚠️ by removing the
client-oauth2 dependency from our JS Auth wrapper. The whole library has been rewritten and the old getSalesChannelToken, getCustomerToken, getIntegrationToken, authorizeWebapp, and getWebappToken functions replaced by a single new authentication function. You can check the updated code samples in the repo README.Be advised that we introduced a potential breaking change ⚠️ by updating our APIs rate limits. The new policy is way more granular and efficient, being differentiated not only by limit type but also by environment, HTTP method, and resource type. We also improved the response headers and deprecated some of the old ones. You can find all the information on the dedicated page of the documentation.
We’ve introduced a new boolean attribute
use_subtotal for shipping methods and order amount promotion rules. It that enables you to compare the order’s subtotal (instead of the total amount, which remains the default) with:- The value specified as the free over amount for the cost of a shipping method.
- The value specified as the amount above which a promotion should be triggered.
In both cases, this way, existing discounts (if any) are excluded from the compared order’s amount.
We’ve introduced a new API endpoint that allows you to apply tags to most of Commerce Layer’s resources. Tags can be used as anchors to build custom logic and processes on top of our API and effectively expands the extensibility of our entire platform.
Tags can be included as associations of the related resources and leveraged to filter a list of a specific resource type. Tags can be also exported and imported in JSON or CSV format, both standalone and together with the related resources.
When a resource is tagged (or the list of the associated tags changes) a specific event is triggered, the related webhook is fired, and the associated tag(s) are automatically included in the callback's payload.
We just released
v5.0.0 of our JS SDK, introducing some new features and breaking changes ⚠️ mostly related to the latest OpenAPI schema update. Please find here below a summary of the most relevant ones — now:- Some fields (e.g. statuses) have a predefined set of allowed values.
- Non-fetchable fields aren’t returned in the related object.
- The control on the resource type has been reinforced.
- You can use the new
count()function when filtering every resource to get the total number of returned elements based on the filter that has been applied. - The overall code has been optimized to slightly reduce the package size.
… and more. Check the release notes and the open-source repo README for any additional information and examples.
v1.0.0 of our Exports CLI plugin is out! Now you can create a new export, list all created exports, show the details of an existing export, and check the resource types that can currently be exported — all from the command line. To learn more about the plugin commands and options, please refer to the open-source GitHub repo README.Commerce Layer now includes a few new endpoints to supplement our existing order subscription functionalities:
- Subscription models — define the frequency and split of subscriptions. Each subscription model can also be associated with a market to differentiate the subscription strategy within different markets. This object allows brands to manage the frequency and payment source of the subscription, as well as attach promotions on the first order of the subscription (often used to discount first runs or provide a free trial of the product). It also can apply subscriptions at the SKU level (not the order level only), which enables orders to be split between one-time purchases (e.g. a razor handle) and subscription purchases (a monthly order of razor blades).
- Order subscription items — determine which items are part of the subscription, making it much easier to change out items in the subscription when required.
- Recurring order copies — are used to automatically generate recurring orders based on a source order and the information set at the subscription model level.
- Order factories — an immutable API that wraps recurring order copies and the already existing order copies resources to enable both automatic and manual order subscription generation.
- Price frequency tiers — enable specific pricing for an item if it’s part of a subscription (e.g. charging $15 for a razor pack as a one-time purchase and charging $12 for the same pack if it’s part of a subscription). You can also provide different prices for different plans (such as charging $12 for a monthly pack of razors or $120 for a year of monthly razors).
To enable all the above, we also made some changes to the line items and orders API: now line items can have a
frequency and the automatic order subscription generation is triggered at the order level by sending the _create_subscriptions attribute.Check our data model and read our blog to get a high-level idea of how the whole process works and how these new features make it much easier to build out sophisticated subscriptions. Find any additional details in the API reference and follow this guide to learn how to set up automatic subscriptions on Commerce Layer..
We bumped our schema to the latest OpenAPI specification. Be advised that we introduced a potential breaking change ⚠️ by updating the server URL syntax for the organization slug since OAS
v.3.1.0 does not support double curly brackets for variables anymore — {{your-organization-slug}} is now {your_organization_slug}. On top of that, we introduced the nullable key which is false if the related property is fetchable and required on creation, true if the related property is fetchable but not required on creation, and not present if the related property is not fetchable. We also added the enum key for the resources that have a status-like property (e.g. status, fulfillment_status, payment_status, etc.) so that all the available statuses are properly listed.Be advised that we introduced a potential breaking change ⚠️ — Starting from v4.0.0 the Checkout application will adopt React 18 and the latest version of our React components library.
Commerce Layer Metrics API standard queries cover a wide range of use cases for your business. Since some use cases are more common than others, we decided to expose more dedicated endpoints to help you get relevant results with simple, customizable queries. The first of these endpoints is FBT, aka Frequently Bought Together, a type of analysis query that retrieves items most frequently added to the same orders as a specified item (SKU or bundle) or a group of items. Stay tuned, there’s way more to come!
Commerce Layer admin dashboard now features a brand new Hub section for back-office applications built on top of our APIs that will facilitate the use of some of the main features of the platform. You can access it from the dashboard sidebar menu. The three apps available in this first version of the hub are imports, exports, and webhooks (stay tuned, more apps coming!). Each of them provides you with a user-friendly UI that lets you handle all the operations involved in the related topic management (previously available via API only).
In addition to this, we also added the search functionality when browsing your account organizations list.
Commerce Layer API now supports Axerve out-of-the-box (in addition to all of our other payment gateway integrations). On top of that, we’ve also added, at the payment method level, two specific features related to payment capture:
- Auto-capture — now, you can ensure payments are automatically captured as soon as they are authorized (for gateways that support it). If needed, you can specify a threshold for auto-capture so that it is enabled only for orders under a certain amount.
- Delayed capture — now, you can override the default behavior of the API and decide to start fulfilling your orders even if they’re not captured yet, waiting to capture them when they’re ready to be shipped.
We doubled the maximum number of SKU list items that you can add to a single bundle, which now changes from 5 to 10. We also increased the maximum import size limit at the API level: now the inputs array can contain a maximum of 10000 items (previously 2000).
Be advised that we introduced a potential breaking change ⚠️ — Starting from
v3.0.0 the Checkout application will adopt the Adyen Payment API v68, dropping the support for v66. Make sure that your Adyen payment gateway is configured properly. This will also introduce the new version of the adyen-web package that is going to improve the drop-in component and the 3DS2 management.We’ve updated and improved our out-of-the-box integration with Adyen which now supports the latest version (
v68) of their Checkout API by default and lets you leverage their notification webhooks system (the only way to receive automatic updates about requests that are processed asynchronously). If you're using an old integration that requires a version lower than
v68 (back up to v66) make sure to specify it in the api_version attribute of the Adyen gateway and use the correct version of Adyen's JS SDK and client libraries as detailed on Adyen's website.Commerce Layer JS Drop-in library
v1.1.0 now dispatches to the document object some custom events (when an item is added to the cart, and when a price or an SKU is fetched) that you can intercept to trigger specific actions on your side. To avoid the same event being fired too often a debouncing practice is also implemented.With
v4.2.0 we added to our subsets of payment gateway and payment source components the external gateway and the external payment ones. These components enable developers to process payments once they have an external payment gateway correctly set up on Commerce Layer and can be used in any custom React project or in a forked version of our Checkout application.We’ve implemented a new custom validation process that enables you to apply additional validation rules on top of our standard validation. This can be useful when you want to support more complex validation rules specific to your business logic, such as market-specific quantities or SKUs.
External order validation setup happens at the market level, where you can specify the
external_order_validation_url of your external service endpoint and find the generated shared secret that you can leverage to verify the related callback authenticity. To trigger the external validation for an order you need to update it and set the _validate attribute to true.Last modified 1d ago