Action Required / Admin GraphQL API

Market-driven shipping
Shipping settings move from delivery profiles to Markets

Merchant shipping settings move from the delivery profile API to the Markets API. Shipping options are attached directly to each market, and rates are differentiated by product and location conditions within a single option. The feature preview is available starting today.

On this page
  1. What actually changes (understand it in 30 seconds)
  2. How it works: where do shipping settings move to
  3. Impact on apps (4 changes)
  4. Traditional vs. Market-driven comparison
  5. Migration schedule (timeline)
  6. What to do now (feature preview in 3 steps)
  7. 5 points developers should know
  8. 3 use cases you can put to work
  9. One-line summary for proposals

1What actually changes

Until now Merchant shipping settings lived in the delivery profile was where they were kept.
With Market-driven shipping, that moves to Markets Shipping options are attached directly to each market,differentiating rates by product and location conditions within a single optionis the new approach.

Traditional: consolidated in delivery profiles

Merchant shipping settings are managed on the delivery profile API. Rate variation was expressed through the profile structure.

Market-driven: attached directly to markets

Shipping options are attached directly to each market. Rates are differentiated by product and location conditions within a single option, making checkout rate behavior easier to predict.

2How it works: where do shipping settings move to

Delivery Profile API Merchant shipping settings (today's merchant delivery profiles) moves from here Move Markets API Per-market shipping options Differentiate rates by product conditions Differentiate by location conditions Checkout shipping rates Merchant rates (from Markets) App-provided rates (still shown in parallel via the existing API) Both appear on the same screen App Delivery Profile stays as is
Key point: only the "merchant side" changes.
What moves ismerchant-owned delivery settingsonly.App-created delivery profiles (app delivery profiles) keep using the delivery profile API as before. App-provided rates are also shown alongside merchant rates within the new experience.

3Impact on apps (4 changes)

Action required

1. Merchant delivery settings move to the Markets API

Today's merchant delivery profiles move from the delivery profile API to the Markets API. Apps that read/create/update merchant delivery settings need to be updated.

No change

2. App delivery profiles stay on the existing API

Delivery profiles created by apps keep using the delivery profile API as before. Nothing changes here.

No change

3. App-provided rates continue to be shown side by side

Rates defined within app delivery profiles continue to be shown next to merchant rates in the new experience.

Enhancement

4. App delivery profiles become more powerful

Instead of only a subset of products, they can now target all products . In addition, adding products to an app's profile no longer affects merchant settings.

Action is required for apps that read from or write to merchant delivery settings via the delivery profile API. If that applies to you, updating your code is required.

4Legacy vs. Market-driven comparison

ItemLegacyMarket-driven shipping
Where merchant delivery settings live Delivery Profile Delivery profiles Markets Attached directly to each market
API used Delivery Profile API Markets API (for merchant settings)
How rates are differentiated Expressed through profile structure Within a single option Branched by product and location conditions
App delivery profiles Only a subset of products / additions ripple into merchant settings Can target all products/No impact on merchant settings
Displaying app-provided rates Alongside merchant rates Continues to display side by side
Predictability of checkout rates — Improved Behavior becomes easier to understand

5Migration schedule (timeline)

2026-07-01Today
feature preview becomes available. Enable the feature preview in a new development store and validate your existing integrations and rate logic right now.
2026-10-01Rollout begins
Market-driven shipping Begins rolling out to merchants. It will be turned on progressively.
2027-07-01Full migration
All merchants will have completed the migration to Market-driven shipping .
About 3 months until the rollout begins (2026-10-01) About 3 months. For affected apps, it's safest to finish validating and updating during the preview period.

6What to do now (feature preview in 3 steps)

1

Create a new development store

Set up a new development store for testing.

2

Enable the feature preview

Turn ON the feature preview for Market-driven shipping.

3

Validate your existing integrations and rate logic

Confirm that your current integrations and rate logic work correctly under the new approach.

Detailed mechanics and upgrade instructions are in the official documentation "Market-driven shipping feature preview" . The standard approach is to get a feel for the behavior in a preview environment before updating production.

75 points developers should keep in mind

1. The API differs between "merchant settings" and "app settings"

Merchant delivery settings use the Markets API, while app delivery profiles use the traditional delivery profile API.Which one your app touchesis the first step to take stock of.

2. If you read or write it, it "requires action"

Apps that read or write merchant delivery settings via the delivery profile API read / create / update must be updated. This is why they're tagged Action Required.

3. Two key deadlines: "start" and "finish"

Rollout begins 2026-10-01, and all merchants complete migration by 2027-07-01.October is the backstop, and finish your validation during the preview period.

4. Watch the non-breaking change to App profiles

Adding products to an app profile no longer propagates to merchant settings. If you have logic built on this side effect, now's the time to revisit it.

5. All-product targeting is unlocked

app delivery profiles can now target all products, not just a subset of products. Pricing logic that was previously designed around narrowing the target set can be redesigned to take advantage of all-product support. The safest first step is to confirm the actual behavior in a new development store's preview.

8Three use cases you can put to work

API
USE CASE 1

"API migration impact assessment" for shipping apps / integrations

Challenge
Your own app or an installed shipping app reads and writes merchant shipping settings via the delivery profile API, and leaving it as-is risks breakage from October onward.
Approach
Take inventory of your code and classify it into "places that touch merchant settings (require migration to the Markets API)" and "places that touch app delivery profiles (unchanged)." Identify the calls that need to be migrated.
Impact
The scope and effort of the rework are locked down before the rollout begins (2026-10-01), avoiding outages caused by scrambling to catch up.
Technical notes
In scope if you touch merchant shipping settings in any of read/create/update. Do regression checks in a new development store's feature preview.
USE CASE 2

Rebuilding "per-market shipping rate design" for multi-country stores

Challenge
You sell across multiple markets and force rates to vary through the delivery profile structure, making checkout shipping behavior hard to read.
Approach
Move your design to the Market-driven approach, attaching shipping options directly to each market and branching rates within a single option based on product and location conditions.
Impact
Checkout rate behavior becomes easier to predict and explain, reducing shipping-related inquiries and configuration mistakes.
Technical notes
Validate product-condition and location-condition branching against real data in the preview. Confirm that your existing rate logic can be reproduced in the new model.
App
USE CASE 3

Enhancing a shipping app with "all-product targeting" support

Challenge
Your shipping app could previously target only a subset of products, so you built workarounds to apply uniform rules to all products. On top of that, adding products propagated to merchant settings, making incidents easy to trigger.
Approach
Use the enhanced app delivery profiles to re-implement your rate rules to target all products. Safely add products, given that there is no impact on merchant settings.
Impact
Removing the workarounds simplifies the code, gives peace of mind that merchant settings won't break, and boosts the app's appeal by expanding its coverage.
Technical notes
app delivery profiles remain on the delivery profile API. Confirm the all-product targeting and non-propagation behavior in the preview before shipping to production.

9A one-line summary you can use in a pitch

"The merchant's shipping settings Migrating from delivery profiles to Markets, a new approach that attaches delivery options directly to each market and differentiates rates by product and location conditions.
Apps that read and write merchant settings via the delivery profile API will need updates(the app profile side stays as-is and is enhanced with support for all products).
The feature preview starts today. Validate before rollout begins on 2026-10-01 and full migration completes on 2027-07-01.