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

Fulfillment & Inventory
45

Hey Aditya, thanks for the questions.

Variant-level rates

Good news — product collections can now target variants, so market-driven shipping can operate at the same level of granularity.

Multiple delivery profiles

App profiles can target the same products as are in merchant profiles, so if the desire is “I want this app rate for products X, Y, Z,” that should work well with app profiles. Let me know if I’m missing a specific use case here.

Compliance and migration

Starting October 1, if an app isn’t compatible, merchants will see a warning on app install and on the shipping settings page that the app is not compatible with market-driven shipping. In addition, merchants can choose to opt in to market-driven shipping.

Importantly, Shopify won’t move merchants that use your app automatically until it confirms your app is compatible. More details in our upgrade guide.

I hope that helps.

46

Hi @drew-shopify

We have Carrier Service API app. We only read shipping config for one reason - to show the merchant whether our carrier service is attached for a given delivery country. A few things did cost us time:

First, we need one market but have to fetch all of them. Our settings are per country, so on a given screen we only care about the market that serves that country. There’s no way to filter markets by region, so we pull the whole list and match on our side. Which means page size is now what decides whether a big store resolves at all. A region: filter on markets(query:) would fix this completely.

Second, marketsResolvedValues(buyerSignal: {countryCode}) doesn’t return the market. It really reads like “which market serves this country” but you only get currency, catalogs and web presences back. If market was in there, nobody would have to reimplement the precedence rule themselves (explicit market wins over applicationLevel: ALL).

Third, read_markets re-prompts every installed merchant, and all we need it for is a read-only panel. From the merchant’s point of view nothing changed in the app, so it just looks like we’re grabbing permissions.

And a smaller one: some markets come back with delivery.shipping: null. Docs say that means it inherits from the parent market, but Market has no parent field anywhere, so we fall back to the primary market and hope that’s the right call. Either expose the parent or resolve it server-side so the field is never null.

47

Just one small concern regarding multiple delivery profiles: can merchants replicate existing merchant-created shipping profiles into app-based profiles?

A merchant with hundreds of products spread across 10–15 different shipping profiles would find it extremely time-consuming to recreate those profiles manually, especially if they have to add products one by one. Is there a way to migrate or replicate these existing product assignments?

Doing it programatically via an app would also take a long time for such stores given Shopify’s GraphQL query limits.

48

Another query I had:

Currently, many of our users have a single market (e.g., Europe) with multiple shipping zones (Europe Zone 1, Europe Zone 2, Europe Zone 3, etc.).

When Shopify migrates these users to market-driven shipping, what process will be followed? Will Shopify create multiple markets to reflect the existing shipping zones, or is there another approach to preserve this setup? I can give you two simplified exmaples to make my query clearer -

Example 1:-

Market 1 - UK
Market 2 - France, Germany, Italy

General Profile:

  • Zone A (UK, France)
  • Zone B (Germany, Italy)

Example 2:-

Market 1 - UK
Market 2 - France, Germany, Italy

Shipping profile A:

  • Zone A (UK, France)
  • Zone B (Germany, Italy)

Shipping profile B:

  • Zones C (Germany, France)
  • Zone D (UK, Italy)

How will the markets look after migration in the above examples?

Apologies if my queries are bit naive, but I just want to ensure seamless transition for our clients. We are a shipping rate app btw.

49

Hi @drew-shopify.
We’re updating our app to support market-driven shipping per your guide ( Upgrade your app for market-driven shipping ), reading shipping configuration via Market.delivery (Option B) for merchants on the new model, and detecting which model a merchant is on via ShopFeatures.marketDrivenShipping. Since our app still calls the legacy deliveryProfiles query for merchants who haven’t migrated yet, we’d like to confirm a few points before finalizing our rollout, to make sure our code doesn’t accidentally trip the “app is not compatible with market-driven shipping” warning.

1. Is submitting the compatibility form to have the “not compatible with market-driven shipping” warning removed mandatory for all apps? Is there a hard deadline by which this form must be submitted?

2. After an app has submitted the form and had the “not compatible” warning removed, does calling deliveryProfiles afterward re-trigger that warning? Specifically:

a. If the store has not migrated to market-driven shipping (ShopFeatures.marketDrivenShipping = false), does a deliveryProfiles call from our app trigger the warning again?

b. If the store has migrated (ShopFeatures.marketDrivenShipping = true), does a deliveryProfiles call from our app trigger the warning?

c. More generally, does any deliveryProfiles request from our app - regardless of the store’s migration status - risk triggering the warning?

3. Does Shopify actively monitor/detect automatically deliveryProfiles API calls from an app in order to flag it as not compatible by auto-detection?

4. Is the “not compatible” status evaluated per store or app-wide? In other words, if our app calls deliveryProfiles only for stores still on the legacy model (per ShopFeatures.marketDrivenShipping = false), could that still affect our app’s compatibility status, or globally across all our installs?

I am concerned about the auto-detection warning after 1/10 and have already submitted the form.

We want to guard against any conditions that could unintentionally cause deliveryProfiles to be called in a way that flags the app as not compatible. It will help us design the right safeguards.

Thanks for your help.

50

Hi all! We are hosting a partner webinar on fulfillment updates including market-driven shipping. Drew will be presenting! Register here: https://www.shopify.com/webinar/partner-fulfillment

51

Hey Patrick, one clarifying question off the bat — could you place your carrier service inside an app profile instead? Then the service will appear under the right markets based on the zones you’ve specified in that app profile and you don’t have to use the markets permission/query.

52

Hey Aditya, I may not be fully understanding the scenario, but merchants shouldn’t be touching app profiles (and in fact, they can’t modify them). They manage their rates in markets and use product collections and location conditions to do so. Apps profiles are for apps to manage rates, and they project their rates into markets automatically.

53

Hey Aditya, check out my post here Market-driven shipping is now in feature preview — action may be required for your app - #15 by drew-shopify

Let me know if that doesn’t clarify things. But the short answer is yes, Shopify will create new markets to accommodate the prior zone setup on merchant-managed profiles.

54

Hey William, good questions.

The thing I want to emphasize is that the form, while not mandatory, is the best way to ensure warnings will not be shown for your app. Once you’ve submitted the form you will be marked compatible regardless of future call behavior. So if you’re worried you’ve submitted the form and will later trigger incompatibility warnings anyway, you can rest easy on that.

Of course, it’s very important that you’ve reviewed your integration carefully to avoid any breaking behavior for your customers before submitting the form.

There is no deadline for submitting the form, you can submit it after Oct 1 if needed.

To briefly touch on your other questions, the incompatibility detection does take into account whether the shop has migrated to market-driven shipping, and the incompatibility state is app wide.

Hopefully that helps with your concerns, if not, let me know!

55

Hi @drew-shopify,

We’ve updated our installation flow to support stores already using market-driven shipping, following Option B of the writers upgrade path in the upgrade guide.

We’d like clarification of the expected behaviour for existing merchants who will be migrating from delivery profiles to Markets.

During testing, we observed the following:

  • We created a store with the Markets preview enabled, then opted out to test the migration process.
  • We installed our app and added our carrier service to the default delivery profile as normal (to be clear here, this is without interacting with the Markets API).
  • We re-enabled Markets and observed that the carrier service was automatically mapped in the Markets configuration which corresponds properly to its original placement in delivery profiles.

Based on our testing, it appears that no action is required on our part for existing installations. Third-party carrier services seem to be properly mapped during migration, regardless of which shipping profile or zone they are associated with.

Could you please confirm that this is the expected and reliable behaviour?

We’re asking because Option A of the writers upgrade path is presented as the preferred approach for forward compatibility, but it doesn’t appear to be necessary in our case (namely creating an app-owned delivery profile).

Given the potential impact on merchants’ ability to complete sales, we want to ensure that the migration is seamless and that existing carrier service configurations will continue working without intervention.

Thank you for your time and guidance!

56

Hey Levi,

You’re right that any existing rates will cleanly move over as part of the migration. The migration preserves existing behavior exactly as is.

However, trying to create rates under the general profile once a merchant is migrated to market-driven shipping will fail (e.g. say this is a merchant on market-driven shipping that installs your app for the first time). That’s because the general profile no longer exists.

At that point, adding the rates requires either an app profile or the use of the markets API.

That’s why Option A is recommended where possible — if you add the rates this way now, nothing changes once market-driven shipping is the norm and you don’t need to use the markets API.

Hope that helps!

57

Hi @drew-shopify,

I also have the same question as @Angelina_Prokopeva asked above. I don’t see it answered yet. Could you please help with this?
(Market-driven shipping is now in feature preview — action may be required for your app - #38 by Angelina_Prokopeva)

Quoting her question -

is there a reasonable way to identify if the variant is shippable and how many items of the variant are shippable in the buyer context using Admin API?

The buyer context is: company Location ID, country code, province code.

To answer a simple question if the product is shippable or not in a buyer context.

I guess this resolution will go across the new B2B market and regional markets.

Previously, we could get this information by querying the delivery profile on the variant, then checking which countries are included in the delivery profile, and which inventory locations serve that delivery profile.

Now from the ProductVariant object in the Admin GraphQL API, it doesn’t seem like there is any equivalent for delivery profiles.

Thank you.

58

Awesome, thanks for the info @drew-shopify!

59

Hey, sorry I missed the original question.

There isn’t a direct equivalent on ProductVariant. With market-driven shipping, you start from the applicable market’s shipping configuration and work out which rates apply to the variant.

The path is Market.delivery.shipping → shipping options → rate groups. Each group exposes product collection and origin location conditions:

  • If there are no collection conditions (collections: null), the group applies to all products.
  • Otherwise, check whether the variant is included in the specified collections.
  • For matching groups, use inventory at their origin locations to calculate available quantity.

So the main change is that your app needs to match the variant against the applicable market’s configuration, rather than follow a profile directly from the variant. This is the Markets API reader path in our upgrade guide.

Another option, if your app operates as a sales channel or can become one, is Contextual Product Feeds. They provide delivery option estimates per variant by country and province/state, so you don’t need to interpret the shipping configuration yourself. They don’t support B2B, though, so they won’t cover the company-location context you mentioned.

60

Thanks so much for the reply @drew-shopify !

Quick follow up question -

3 points here -

(a) Currently (even on the release candidate version) in Admin GraphQL API, the MarketsResolvedValues object doesn’t have a delivery object.

(b) I have not been able to find any way to resolve the matched market in the Admin API, since there is no guarantee that a country code will uniquely resolve to a single market.

(c) Also Markets.delivery.shipping can be null, which means that we need to inherit the settings from the parent market, but there is no way to know which market we are on and which market are the parent markets on the latest API version. The release candidate does seem to have a new ParentMarketsfield but that only applies if we know which is the currently assigned market, and also it’s only on the release candidate version which would be stable only on Oct 1 or later, and that is the time when the rollout would already have begun (so the timing feels unideal to me)

Can you please help with clarifying the above? It will be very helpful.