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).

Default payment method

You can create a specific payment method and set it as the default payment method for one or more markets by leveraging the default_payment_method relationship. This way all the market's orders not already associated with a payment method will be automatically associated with the default one.

To be eligible for being set as default, a payment method must not already be associated with any markets. Otherwise, the API will return an error when associating the relationship.

Default shipping method

You can create a specific shipping method and set it as the default shipping method for one or more markets by leveraging the default_shipping_method relationship. This way all the shipments that belong to the market's orders and that are not already associated with a shipping method will be automatically associated with the default one.

To be eligible for being set as default, a shipping method must not already be associated with any:

• Markets

• Stock locations

• Shipping categories

• Shipping zones

Otherwise, the API will return an error when associating the relationship.

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_url field 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_url field 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.

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.

Data model

Check the related ER diagram and explore the flowchart that illustrates how the market resource relates to the other API entities.