Shopify is gradually moving merchant shipping settings into Markets. If an application reads or changes those settings, check compatibility and test your shop's real destinations, products and delivery options. A successful API response does not establish that checkout uses the intended rate or that your shop has already switched to the new model.
What does shipping configured through Markets mean?
Selling across regions introduces differences in destination, product, warehouse and collection. A rule that looks correct in a settings screen can fail when another application changes rates. The challenge involves knowing which system controls the configuration, as well as setting an amount. Without that ownership, the team may be checking a screen that no longer represents the active rules.
Shopify announced a Markets-based shipping model in July 2026. Its documentation describes merchant shipping settings associated with individual markets, with conditions relating to products and locations. This changes where integrations managing merchant-owned delivery configuration need to read and write. It does not mean every carrier, plan or shop immediately receives identical options. Availability must be checked for the actual shop and its dependencies.
The key distinction is between merchant-owned delivery profiles and profiles owned by applications. Shopify explains that application profiles continue using their corresponding APIs and that rates supplied by those applications remain part of the new experience. An audit that searches for delivery profiles and replaces everything indiscriminately could therefore damage an integration that is still valid. Identify the ownership and purpose of each resource first.
For the ecommerce manager, the purpose is to protect the shipping option shown to the buyer and the information received by operations. A new API alone is not a business reason to migrate. If a buyer reaches payment and sees an inappropriate option, explaining the technical change afterwards is too late. Start from the purchase journey and work backwards through the rules that produce it.
How can you identify an affected integration?
List the tools involved in calculating or maintaining shipping: rate applications, logistics connectors, warehouse software, internal automations and scripts updating rules. Ask each provider whether its integration reads or changes merchant-owned shipping settings or only uses application-owned profiles. A general statement that the tool is compatible with Shopify does not answer that narrower question.
The official upgrade guide, accessed on 16 October 2026, identifies marketDrivenShipping in ShopFeatures as a way to detect the model used by a shop. It explains that integrations managing merchant-owned configuration must move to the appropriate Markets APIs or another compatible approach, depending on their function. Do not infer the shop's state from the calendar alone: activation can depend on application compatibility and adoption decisions.
Request a simple map showing where a rule starts, which system changes it, where the outcome is checked and who owns it. If two tools can edit the same criterion, document which one is authoritative. If one displays rates while another updates them, include both in the test. An unexplained exception for a bulky product is itself an operational issue worth resolving before migration.
Before changing production, preserve a description of current rules and exceptions. Include normal destinations, excluded areas, restricted products and any collection or delivery combinations actually used. Define expected outcomes for each scenario. Fictitious test data can exercise those rules without using customers' personal details or placing an unintended live order.
What should you test at checkout?
Begin with a scenario matrix rather than a single test purchase. A basket containing one ordinary product does not demonstrate that mixed items, destinations and warehouses work together. Include relevant product characteristics, different markets, configured free-shipping conditions, collection where offered, and application-supplied rates. Record the option that should appear and the reason. Confirm plan and configuration support instead of assuming a feature is available.
Shopify recommends a development shop with the market-driven shipping preview to validate read and write paths. An integration consulting the older configuration may show an outdated picture. More subtly, Shopify warns that some older mutations affecting merchant-owned profiles can complete without an error while leaving active settings unchanged. An operation marked completed in a log is therefore insufficient evidence of a checkout change.
Verify the final effect. After changing a rule in a test environment, read the authoritative configuration again and reproduce the corresponding checkout. Compare both the visible option and the logic behind it. When several applications participate, test with the relevant combination, then use a controlled variation to investigate interference. Keep expected rule, observed outcome and corrective owner together in the record.
Mixed shipping and collection in a single order deserves attention where the shop uses supported functions of that kind. Shopify notes that delivery and fulfilment information may move differently between systems even without a dedicated new API for that experience. If your business does not offer it, do not invent a testing obligation. Prioritise journeys that exist and those planned in the near future.
Which dates matter without creating a false deadline?
The official roadmap places developer preview in July 2026, the start of merchant adoption on 1 October 2026 and broader rollout by July 2027. These are Shopify's published milestones, not proof that your particular shop has changed. The guide warns that target dates can change and that automatic activation for some shops depends on compatible applications. Treat dates as planning inputs alongside the actual configuration.
From October, new installations can show compatibility warnings, and merchants adopting manually before an application is ready may encounter failures. Coordinate suppliers and business owners rather than either blocking every improvement or rushing ahead. Name who checks compatibility, who approves the transition and who tells customer support if an option changes. Support needs an explanation it can apply to a real enquiry.
Choose a testing window that avoids a critical campaign where possible. Before activation, record which rules must keep working. During transition, review incidents and enquiries. Afterwards, confirm that warehouse processes receive the information they need. Do not attribute every delivery complaint to the new model: a pricing error, carrier delay and preparation problem have different causes and owners.
If a provider needs to update its application, ask for specific confirmation of the affected paths and test plan. Updated to the latest API is not enough. An integration may use a recent version while still reading a resource that no longer represents active configuration. Functional acceptance means the right rate appears and the next operational steps receive suitable information.
How does this become a useful operating procedure?
The ecommerce manager does not need to memorise every GraphQL mutation. They do need to know who configures shipping, who can change it and how an unexpected change is detected. A shared record can hold the answers, evidence and provider contacts. For a complex system, add periodic review of exceptions and rules. The record should be understandable beyond the developer who first built the connection.
Check that visible delivery choices match the published commercial policy. When support receives complaints about one region, it should be able to identify the applicable configuration without searching several dashboards. An automation can flag a known discrepancy, but should not change shipping prices on its own without approved rules. Escalation and the authority to change a price need to be explicit.
Preparation should not become manufactured urgency. Some shops only need supplier confirmation and checkout testing. Others, with custom rules and applications writing configuration, will require technical work. Base that decision on real dependencies rather than catalogue size or a generic warning about APIs. The proportionate solution protects the purchase journey without adding work that produces no useful evidence.
| Scenario | Expected result | Evidence |
|---|---|---|
| Normal destination | Intended commercial option | Test checkout |
| Restricted product | Specific rule applied | Settings and basket |
| Application rate | Compatible option visible | Provider confirmation |
| Rule update | Read result matches effect | Before-and-after comparison |
How have we approached it at meiika?
We study custom systems through their rules, owners and visible outcomes. In ecommerce, a test should reach the delivery option the buyer sees and the information operations receives. The Growth & MarTech perspective connects that experience with the commercial promise made on the website.
This article does not describe a migration carried out for a client. We cannot guarantee rates or compatibility without reviewing the actual shop. The purpose is to make a technical change understandable as a practical acceptance test, with enough evidence for the business to decide when it is ready.