Markets
The market object and the allowed CRUD operations on the related resource endpoint
A market is made of a merchant, an inventory model, and a price list. Optionally, a market can be associated with different price list schedulers and stores, a customer group, a geocoder, and a tax calculator.
You can define a custom alphanumeric (case-sensitive) code for your markets, provided that it's unique across the environment (it can contain underscore and hyphens, spaces are not allowed, the maximum length is 25 characters).
Sales channels must specify a market scope when obtaining an access token. This way, all the resources (e.g., SKUs, prices, stock items) are automatically filtered. If you put a store in scope instead, there's no need to specify the associated market, which is inherited from the store itself.
Scheduling price changes for a market
To be able to associate a price list scheduler with a market, their price lists must share the same currency_code and tax_included attributes. The price list associated with an active price list scheduler temporarily overrides the one originally associated with the market, letting you change a subset of prices within a specific time window (e.g. seasonal sales). A market can be associated with more than one price list scheduler but, at a given moment in time, only one will be chosen to override the market's original price list (that you can still fetch by checking the base_price_list relationship).
Disabling markets
Markets are automatically enabled at the time of creation, but they can be disabled by sending a PATCH request with the _disable trigger attribute set to true. Similarly, you can use the _enable trigger attribute to re-enable a disabled market. Once a market is disabled it is excluded from any authorization scope recalculation: existing access tokens previously created with that market in scope receive a 422 Unprocessable Entity error on market-specific actions (e.g. if you try to create/update an order or a line item), any attempts to request a new access token with that market in scope receive a 400 Bad Request error (due to invalid scope).
Your plan limits refer to active (i.e. enabled) markets only. 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.
Market-specific shipping costs policy
Based on the selected inventory strategy, an order can be associated with more than one shipment. Each shipment must be associated with a shipping method, the cost of which will result in a line item of type shipments in the order summary. If you want to override this behavior for one or more of your markets, you can set the shipping_cost_cutoff attribute (not enabled by default) whose value will define the maximum of shipping line items of the order that will have a cost, while the remaining ones will have their unit amount set to 0 — e.g. if you set the shipping_cost_cutoff value to 1, only the shipping method that is first associated with an order's shipment will have its cost, while the subsequent ones cost will be zeroed (this way, for example, you can charge the customer with one single shipping cost for the whole order).
External URLs
When setting up a market, you can decide to manage some market-specific features using an external/custom service. Specifically:
Prices — fill in the
external_prices_urlfield with your external service endpoint and follow the external prices guide for more information on how to inject the unit amount price of a specific line item from an external source.Order validation — fill in the
external_order_validation_urlfield with your external service endpoint and follow the external order validation guide for more information on how to trigger the validation of a specific order from an external source.
When activating both of the features above, a shared secret is generated at the market level. You can use it to verify the related callback authenticity.
Last updated