Stores
The store object and the allowed CRUD operations on the related resource endpoint
Last updated
The store object and the allowed CRUD operations on the related resource endpoint
Last updated
The store resource enables you to map a market's physical shops (e.g. retail stores, pop-up stores, etc.) to effectively manage in-store sales and more. To create a store you have to give it a name and set the market it belongs to. If needed, you can specify a different merchant (otherwise it will be inherited from the associated market), assign the store's stock location, and enable store-specific payment methods.
You can optionally define a custom alphanumeric (case-sensitive) code for your stores, provided that it's unique across the environment (it can contain underscore and hyphens, spaces are not allowed , the maximum length is 25 characters).
A store can be when requesting an access token so that:
All the fetched resources (e.g. SKUs, prices) are automatically filtered by the market the store is associated with.
Orders created with a specific store in scope belong to both the store and the associated market.
The stock availability is computed taking into consideration the store's stock location (if any) first.
The available payment methods are updated accordingly.
The shipments management for items available in store is simplified.
Stores are a beta feature, still open for improvements and refinements. We encourage you to try it out and share any feedback that could help us enhance its fit for your use cases.
The stock availability with a store in scope is calculated according to the following logic:
If the store has a stock location and the associated market has an inventory model with different stock locations, the market stock locations hierarchy is extended by adding the store's stock location as the one with the highest priority and increasing by 1 the inventory model's stock_locations_cutoff value.
If the store's stock location already belongs to the associated market's inventory model, the store's stock location priority in the market inventory model is updated (set to 0 — i.e. the highest), without increasing the cutoff.
If the associated market has an empty inventory model (i.e. with no stock location defined), only the store's stock location is considered (e.g. you can create a market that contains all of your brand's stores and decide to sell using the single stores' stock only).
If the store has no stock location, the associated market's stock location hierarchy (as defined in the related inventory model) is used as a fallback.
This logic enables you to sell from your store items that are not physically in-store leveraging the inventory model of the associated market, thus making endless aisle possible.
The available payment methods with a store in scope are returned according to the following logic:
If the store has one or more specific payment methods enabled, the returned available payment methods are the store's only.
If the store has no specific payment method enabled, the returned available payment methods are the associated market's ones.
Shipments associated with orders belonging to a store are created as usual and honor the selected inventory strategies (taking into consideration the new stock location hierarchy due to the addition of the store's stock location, if any).
Shipments that don't involve stock transfers from other stock locations of the associated market and that have only stock items belonging to the store's stock location are automatically considered dispatched to the customer directly from the store operator, meaning that:
They don't need to be associated with any shipping method.
They are marked as delivered as soon as the related order is placed.