Market-driven shipping is now in feature preview — action may be required for your app

[drew-shopify]

Hey everyone

We’re beginning to roll out market-driven shipping, an upgrade to how merchants configure shipping in Shopify. It moves shipping options into Markets, so merchants can manage where they sell and how they ship from the same place in Shopify admin. This change gives merchants a clearer shipping setup, better support for different buyer contexts, and more predictable rate behavior at checkout. It’s now in feature preview and available on the latest API version, and we want to get it in front of you early so you have time to test and upgrade ahead of merchant rollout.

If your app creates or updates merchant shipping configuration, please read on — there may be action required.

What’s changing

Today, merchant shipping configuration lives in delivery profiles. With market-driven shipping, it moves into Markets: merchants attach shipping options directly to a market, then vary rates by product and location conditions inside a single option. Because related rates live inside one option, Shopify can charge the highest matching rate rather than adding them together — so buyers stop seeing inflated shipping prices the merchant never intended. Shipping can also be set specifically for B2B or POS markets.

A few things to know up front:

• Merchant shipping configuration (today’s merchant delivery profiles) moves from the delivery profile API to the Markets API.
• App delivery profiles (delivery profiles created by apps) keep using the delivery profile API — that path isn’t changing.
• App-provided rates (rates defined within app delivery profiles) still appear alongside merchant rates in the new experience.
• App delivery profiles are getting more powerful: they can now target all products instead of just a subset, and adding a product to an app profile will no longer impact the merchant configuration

Does this affect my app?

It might. It depends on how your app uses shipping configuration:

• You only manage your own profiles (app delivery profiles) → No action needed. They keep working and appear in the new experience as app-provided rates.
• You read or write merchant shipping configuration → This needs your attention. The right path depends on how your app uses the configuration — the upgrade guide walks through the options.

Start with the overview for how the feature works, then the upgrade guide for the path that applies to your app.

Timeline

The feature preview is available now on the latest API version. Market-driven shipping will start rolling out to merchants on October 1, 2026, and all merchants will be on it by July 1, 2027.

Come October 1, merchants using your app can choose to opt in, and Shopify only auto-enables market-driven shipping for a merchant on your app once we’ve confirmed your app is compatible. There are two things to keep in mind from that date: new installs see a compatibility warning until your app is marked compatible, and a merchant who chooses to opt in before your app is ready may hit breakage. Aim to upgrade and confirm compatibility before October 1, 2026, and be compatible by July 1, 2027, when all merchants will be on market-driven shipping.

Enable the preview on a new development store and validate your integration now, so you have the full window to upgrade before merchants start moving.

FAQ

Do my app-created delivery profiles still work? Yes. App profiles keep using the existing delivery profile API and their rates appear in the market-driven shipping experience.

Can I use this in production yet? Yes, with a caveat. The APIs are on the latest version but they generally only affect shops that have moved to market-driven shipping, and merchant rollout doesn’t begin until October 1, 2026. Use the time before then to test and update your app so that you’re ready when October comes.

Will my existing merchants be opted-in automatically? No, merchants using your app aren’t auto-enrolled in market-driven shipping — they can opt in manually, and Shopify only auto-enables it for merchants on your app after we’ve confirmed your app is compatible.

What happens if I don’t upgrade in time? Apps that aren’t upgraded won’t work correctly for a merchant once that merchant is on market-driven shipping, and new installs will see compatibility warnings. Since we don’t auto-enroll merchants on your app until your app is confirmed compatible, the main risk before you upgrade is a merchant opting in manually. Merchants can also opt out during the rollout if needed, though that’s temporary and all merchants will be on market-driven shipping by July 1, 2027. The safest path is to upgrade during the preview window.

Will my app need new scopes? Usually not, but they are required on some upgrade paths. It depends on how your app uses shipping configuration. The upgrade guide covers what each path requires.

Questions

If anything’s unclear or your use case isn’t covered above, reply in this thread and we’ll work through it with you.

For those interested and in Toronto for DotDev later this month, we’ll be hosting a workshop on day 1 where we’ll walk through the changes and go hands-on with the APIs.

Thanks for building with us

[Kyle_W]

Will this have any impact on Liquid? Take this object, for example: Liquid objects: country_option_tags

[Patrick_Jakubik]

I’m looking at delivery field on Market object and it seems that shipping option title is not there. Is this expected or is it an oversight? There is only description.

Our app is pulling titles of all shipping options by country. We are not sales channel.

[Senior_Dev]

For apps that only read merchant delivery profile data today should we fully migrate that logic to the Markets API once a store enables market driven shipping ?

Is there a recommended way to detect whether a merchant store is already using market driven shipping so the app can choose between the old delivery profile flow and the new Markets API flow?

[lynthius]

Good question, I ran into the same thing. Would be great to have access to the title.

[Teun]

Would love it if this also exposes the shipping rates inside Liquid. Having the market rates available per market would mean we can actually display shipping rates in the cart without workarounds.

[drew-shopify]

Hey Patrick, this is expected.

DeliveryOptionDefinition is an interface. You’re looking for the name field, and it lives on the concrete types that implement the interface. Three of the four concrete types have it:

• DeliveryFlatRateOptionDefinition
• DeliveryValueBasedOptionDefinition
• DeliveryWeightBasedOptionDefinition

The fourth, DeliveryCarrierCalculatedOptionDefinition, has no name because the merchant doesn’t set one. The label buyers see is derived from the carrier itself (carrierService.name, e.g. “USPS”) plus the specific services offered (serviceConfiguration, e.g. “First Class Mail”, “Ground Advantage”).

So to pull all option names by market, query name on the concrete types via inline fragments, and handle the carrier-calculated case separately:

{
  market(id: "gid://shopify/Market/123") {
    delivery {
      shipping {
        optionDefinitions(first: 10) {
          nodes {
            __typename
            ... on DeliveryFlatRateOptionDefinition { name }
            ... on DeliveryCarrierCalculatedOptionDefinition {
              rateGroups(first: 5) {
                nodes {
                  carrierService { name }
                  serviceConfiguration { name status }
                }
              }
            }
          }
        }
      }
    }
  }
}

(The value-based and weight-based types expose name the same way as flat rate)

[drew-shopify]

Take a look at these instructions for readers for info on that including how to detect if a merchant is on market-driven shipping. LMK if that doesn’t answer your questions!

[AdminGh]

Are there any changes to the CarrierService request from Shopify to the Carrier? Could it include the MarketID as well?

[drew-shopify]

Hey Kyle, no impact to liquid, that field will work for Market-Driven Shipping as well. That’s coming soon.

[drew-shopify]

Hey there, no changes to the carrierService request are planned at this time. Market ID might be tricky because merchants can freely delete and re-add markets at any time. What are the fields from the market that would be most useful for you in the carrierService request?

[Min_Liu]

I think being able to see the market id or handle will be beneficial, these new market rules seem really good in letting the customer organise shipping by company/region etc, however merchants may want to setup more complex rules in shipping apps and it will be good if we can identify in the carrier service request which market shopify is querying for so we can target rules.

[Min_Liu]

With the new market driven shipping, self managed delivery profiles are removed completely right? how will merchants who currently have delivery profiles setup be migrated to market driven shipping as it doesn’t look like the same functionality can be sustained with the new featureset?

Are there details as to how existing settings will be mapped to new ones once a merchant needs to migrate as i’m sure merchants will have these questions.

[drew-shopify]

Good question. You’re right that merchant-managed delivery profiles are being replaced by market-driven shipping configurations. But to clarify — the existing functionality can indeed be represented with the new model. And in fact, we plan to execute the migration such that merchants will experience no changes to their rates when they move to market-driven shipping.

Roughly how this will work is:

• Zones will be translated to markets, and new sub-country markets will be added if needed to maintain the same region targeting
• Product groupings in profiles will move into product conditions within shipping options.
  • Since product conditions target collections, we will create new collections on behalf of the merchant. The collections will be unpublished (not exposed to buyers) and labeled “[SHIPPING] + original profile name” (e.g. “[SHIPPING] Fragile”). The products in the collection will be the ones the merchant had in the corresponding shipping profile prior to migration.
• Location groups will move into location conditions within shipping options

We’ll be publishing more info on how this will work in our help docs as we get closer to the merchant roll out.

[Min_Liu]

but product conditions in new market driven shipping applies by taking the most expensive rate rather than adding them together, can you provide an example of how to set it up in the new market driven format where rates for different products adds together?

[drew-shopify]

Using this example for the US market:

• Standard Shipping: $10 for non-fragile products
• Standard Shipping: $15 for fragile products

If a cart contains both a non-fragile and fragile product, and you want the rates to sum together, the setup would be:

US Market:

• Shipping Option 1
  • Standard Shipping $10
  • Product conditions: None (all products)
• Shipping Option 2
  • Standard Shipping $15
  • Product conditions: Fragile products collection

Result at checkout: Standard Shipping $25

If you instead wanted to take the highest rate, the setup would be:

US Market:

• Shipping Option 1
  • Rate 1 (called a Rate Group in the API)
    • Standard Shipping $10
    • Product conditions: None (all products)
  • Rate 2
    • Standard Shipping $15
    • Product conditions: Fragile products collection

Result at checkout: Standard Shipping $15

The idea is that rates within an option will take the highest rate, and rates across options will add together. This applies to flat rates and order-total based weights. Weight based and carrier calculated rates will always sum (and shipping options of those types can’t contain multiple rate groups).

When merchants move to market-driven shipping, we plan to migrate their profiles into the first configuration to maintain existing behavior. They can then choose to move to the second configuration if they want the highest rate behavior.

[Min_Liu]

I’ve been running some tests with this and the carrier service API and a few bugs:

Scenario, i have a product available at 2 locations, 1x qty at each, both have been added to the cart.

Shipping rates set as follows (ignore which ones are active in the screenshot)

The Bespoke app is set to generate a $100 rate per shipment

Test 1:

All above rates are active, we see the accessory combined rate → shows as $3.

Carrier service receives 4x requests, 2 for the first carrier service rate (product needs to come from two locations), and 1 each for the location specific rate. → shows as $100.

Observations:

1. When a rate setup in shopify directly is spanning all locations is active, the location specific ones are ignored. (i.e only the first and last rate in the list shows)
2. However, If the rates are carrier service, the opposite occurs, can you clarify how these are picked?
3. [BUG] the two carrier service call for the first CCS rate has origin location set to the same location, expect one call to be from one location and the other from the other location
4. [BUG] shopify still adds the two carrier service rates together, would expect the behaviour to mimic the rates setup in shopify directly, i.e. one CCS call, and one rate (i.e. shows as $100 not $100+$100)

Test 2:

Only the 4 location specific rates are enabled (that’s #2, 3, 4, 5 in the list above)

Rate setup directly in Shopify shows as $2.1+$2.2 = $4.3 as expected

Carrier service rate shows as $100 + $100 = $200 as expected

Observations:

1. [BUG] the two carrier service API calls use the same address, as with the Test 1. As the product needs to come from two locations, each carrier service call needs to have the origin address set to the respective location.

[Min_Liu]

I’ve tested this with single products which are only available at specific locations in separate carts and the carrier service request always has origin address set to the shop default location.

It appears the origin location is thus not set according to the location where the product is located.

I do note though when adding the rate and listing services, the dummy carrier service request shopify sends does have the correct location.

One more thing i noticed is the origin location name is set to null on carrier service requests related to actual orders, but is set correctly in the dummy carrier service request when you add the rate in and list services.

[FourStacks]

Hi @drew-shopify - can you clarify what you mean when you say that product groupings in profiles will move into product conditions?

As far as I’ve been able to tell, the only two options available in product conditions are “All Products” or the selection of one or more collections.

As delivery profiles currently allow merchants to define a free-form selection of products that should be in the delivery profile. How does this translate into product conditions in a market rate option definition?

I assume you won’t be creating new collections based on the Delivery Profile product selection as part of the migration? Though if not I’m not seeing how this works?

[drew-shopify]

Good eye, that wasn’t clear in my prior response. We will be creating collections for merchants as part of the migration. Edited the response to include the details, relevant section below:

Since product conditions target collections, we will create new collections on behalf of the merchant. The collections will be unpublished (not exposed to buyers) and labeled “[SHIPPING] + original profile name” (e.g. “[SHIPPING] Fragile”). The products in the collection will be the ones the merchant had in the corresponding shipping profile prior to migration.