Thanks very much for the clarification @drew-shopify . Would you mind confirming if this is the case for the General profile too?
Hey @drew-shopify - one question off the back of this. Would you be able to confirm if the currency field on the CarrierService payload will continue to always be the Shop base currency? I’m guessing it will be (and that Shopify will do a dynamic or set conversion on the rate prices that Carrier apps send back) but it would be good to confirm.
So in other words, if the a shops based currency is USD but they have a European market that uses EUR, if a customer in the EU triggers a rate request, we (as a carrier app) will receive that payload with the currency field set to USD. We will respond with rates in USD and Shopify will the convert to EUR at presentation time (using whatever FX config is in that EU market on Shopify)?
That’s right. The currency field on the CarrierService payload will continue to be in the Shop base currency.
Thanks for the thorough details Min Liu.
First, the bug: good catch — we were sending the wrong address to carrier services. The fix is in progress.
On how rates get chosen: this behavior is still rolling out, so you may not see it immediately, but here’s how it will work:
Across multiple shipping options
- If more than one option is needed to ship the cart, their rates sum. Applies to every option type (carrier, flat, weight-based, order-amount-based).
- Example: “Standard” ships item A, “Oversized” ships item B → buyer pays Standard + Oversized
Within a single option
- Flat or order-total-based → the highest applicable rate is used.
- Carrier or weight-based → summed. E.g. a carrier returns a rate per package for 2 packages → the two are added.
Yup, it’s the case for General as well. Collections can now exclude other collections so we will be creating a general collection that includes all products and excludes the other collections we create. That will mimic the General profile’s current behavior where it includes all products that aren’t in other profiles.
cool thanks.
what happens when more than one rate applies, i.e a rate split between two locations and one that spans all locations? from my previous testing only one of them applies, what’s the rules to determine this?
furthermore, whilst this will be a departure from the current behaviour, for single rates that span all locations can carrier service send a single payload to align with the behaviour with rates setup directly in shopify?
also, it will be good for the market currency to be sent via the carrier service request too as merchants generally want to be able to target the specific market currencies or setup thresholds with respect to the selected currency, even if we had a market handle or id we could look this up ourselves.
No problem!
what happens when more than one rate applies
In the future (still rolling out), all rates will be available at checkout instead of some being dropped.
can carrier service send a single payload to align with the behaviour with rates setup directly in shopify?
Unfortunately no, carrier rates will always add together for now.
it will be good for the market currency to be sent via the carrier service request too
Makes sense, I’ll relay your feedback to the team.
Hey @drew-shopify thanks for your answers so far - really helpful to find out some of the nuances.
I have a question off the back of your answer regarding the translation of Delivery Profile products into unpublished collections.
At present, a product (or specifically a product variant) can only belong to a single Delivery profile. If a cart contains items that are in Delivery Profile A and Delivery Profile B, carrier apps get two separate rate requests, one for each profile, an each contains only the items from that profile.
When a merchant switches to market based shipping, Shopify will create unpublished collections containing the products from each Delivery Profile (including General) and will set these on the Shipping Options in a Market that will be created during the migration.
So far this is basically a 1:1 translation from Delivery Profiles to Market-based Shipping.
My question is this: over time, is there anything stopping a product from being present within multiple shipping options that are configured to target different collections?
Let’s say the merchant creates Collection A and Collection B and assigns product variant Alpha to both collections.
In their market they have two shipping options:
Option 1 - contains app carrier rate, assigned to Collection A
Option 2 - contains app carrier rate, assigned to Collection B
My understanding is that if the cart contained:
Item from Collection A (item is exclusively in A)
Product variant Alpha
Item from Collection B (item is exclusively in B)
Then the carrier app will get two rate requests:
One containing:
Item from Collection A
Product variant Alpha
One containing:
Item from Collection B
Product variant Alpha
In this scenario Product variant Alpha potentially gets quoted against twice. Depending on rate configuration this may or may not be a problem but for any rates that are calculated based on weight, quantity, product presence etc it’s definitely going to lead to some double counting
I appreciate that the above scenario holds a degree of merchant culpability (they have to do away with the shopify generated collections and start using their own) but it does feel that once Shopify have done that initial collection conversion that there are no guardrails to prevent this kind of footgun scenario? I can see it being even more of an issue where merchants are setting up shipping fresh and there’s no shopify generated collections even in the mix. A product could potentially popup in multiple rate requests and carrier apps (due to the siloed nature of rate requests containing only items in a Delivery Profile or Shipping Option) have no way to know that they are double counting.
Have I understood this correctly? If so is that just something we’ll have to keep reminding merchants to be wary of?
@drew-shopify will any of these changes allow us to download pre-purchased labels into our apps? You took that function away a while ago, and it would be extremely useful to have it back.
Hi Drew,
Any updates on when this future roll out will occur? It’s incredibly difficult to see what needs to update in our apps and to anticipate issues for existing merchants if the solution isn’t ready for us to test properly.
Are you able to clarify with ‘app owned delivery profiles’ is this just for subscription apps, pre-order or TBYB apps? can regular carrier service apps create their own delivery profile? Looking at the API docs it looks like this requires a selling plan.
Thanks
Following the example on this page:
Using 2026-07 (and also tried on 2026-10)
getting error
Field ‘activeOptionDefinitionsCount’ doesn’t exist on type ‘ShippingConfiguration’
noticed this field isn’t actually listed in docs, is it a typo or a bug?
Testing out the marketUpdate graphql mutation to add rates/carrier service options, a couple of notes:
- there is nothing stopping merchants from adding the same rate (with same conditions multiple times), with carrier services this can generate a lot of additional traffic for shopify and apps, currently shopify doesn’t allow such behaviour and should probably be blocked.
- when adding a new rate, i would like to see the originLocationsToAdd parameter default to add all available locations when omitted, currently it lets you add the rate, but with no locations and thus does not result in any rates - so essentially making the rate invalid.
- In addition to the above, Shopify doesn’t check if the location is actually enabled for fulfilment or not, i can forcefully add in there locations which don’t have fulfilment enabled, and then in the Shopify admin, those locations are hidden
Good questions —
- There is no longer any “mutually exclusive” behavior between profiles / market shipping responders. In other words, nothing stops the same product from being targeted in multiple shipping options. In the initial migration, we maintain the existing behavior via the collection setup, but you’re right that this isn’t the typical behavior going forward when a merchant starts from scratch
- This should be a good thing because the old behavior caused issues with one profile (including app profiles) “stealing” the product away from another, making certain configurations difficullt or impossible to create. This makes app profiles more powerful because they can target whatever products they want without disrupting the merchant configuration
- Yup carriers can get multiple rate requests, but that matches the setup - the merchant is requesting rates for two separate shipping options and both will be presented to the buyer
Hey Tom, I think your question is answered here: Generating Shipping Labels via API - #8 by Bjorn_Dawson
Hi @drew-shopify , we’re SMART Shipping Rates & Rules (client ID 91fa9a072ad5c77ad403d40b895f7ed0).
I’ve ran into an issue: deliveryProfileCreate with coversAllItems: true returns “The API client is not authorized to set coversAllItems on a delivery profile.”
Two questions:
- Is that block the client allowlist, or is it because the store isn’t on the market-driven shipping feature preview? The error doesn’t distinguish.
- If it’s the allowlist, how do we request access?
Our use case: we’re a rate calculator, not a fulfiller. We price the whole cart, so we can’t enumerate a merchant’s catalog into our profile at install time.
Any updates on when this future roll out will occur?
Working on getting you an ETA!
Are you able to clarify with ‘app owned delivery profiles’ is this just for subscription apps, pre-order or TBYB apps?
Any app can create their own profile, it’s not limited to apps with selling plans. For most apps, creating their own profile is the preferred integration path.
@drew-shopify 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.
Hi Drew,
Just testing this out and a few questions. I’m testing on 2026-07 and trying to set coversAllItems: true however get the following error
“message”: “The API client is not authorized to set coversAllItems on a delivery profile.”
What does this mean and how do i work around it? It doesn’t seem like this mutation is creating a ‘app owned’ profile, i can still manually make changes to it in the shopify admin as well.
Furthermore, when adding a carrier service rate via the createDeliveryProfile mutation, it requires methodDefiniationsToCreate.name to be set, however for a carrier service rate, this isn’t settable by the user, the field should be optional for participant rates.
[Update]
Looks like this works on the market driven shipping preview store type but not on a normal store (how do we get it to work on a normal store?), i noticed that it auto adds the app to markets based on the zones defined which is great, however same issues as before, there is nothing stopping the merchant from adding the same app in multiple times - we don’t want merchants accidentally doing this otherwise will duplicate the requests going to apps and will thus result in unnecessary traffic and also slow rates.
Is that block the client allowlist, or is it because the store isn’t on the market-driven shipping feature preview?
It’s the latter — coversAllItems is only available to developer test shops right now, but will be available to all shops in ~2 weeks.
Hey Min, the rate behavior discussed here should now be live for shops on Market-Driven Shipping.