Shopify Release Notes

As of Customer Account API version 2026-10, the deprecated Customer.lastIncompleteCheckout field is removed.

This also removes the now-unreachable Customer Account API Checkout type subtree, including:

• Checkout
• Checkout.appliedGiftCards
• AppliedGiftCard
• AvailableShippingRates
• CheckoutLineItem
• CheckoutLineItemConnection
• CheckoutLineItemEdge
• ShippingRate

The Customer.lastIncompleteCheckout field was previously deprecated and returned null. This change removes stale Checkout Classic schema from the Customer Account API.

Action required

If your app queries Customer.lastIncompleteCheckout or any nested fields on the returned Checkout object, update your queries before upgrading to API version 2026-10.

Remove selections such as:

customer {
  lastIncompleteCheckout {
    id
    appliedGiftCards {
      id
    }
  }
}

There is no replacement field in the Customer Account API.

If you need active cart or checkout state for a buyer storefront experience, use Storefront API cart flows instead. If you need completed customer purchase history, use the Customer Account API Customer.orders field.

Sub-region Markets are available in the Admin GraphQL API 2026-07 release candidate

Apps using Admin GraphQL 2026-07 can encounter Markets configured with country-subdivision regions, such as states and provinces as merchants upgrade to market-driven shipping.

Use MarketRegionSubdivision as the stable country-subdivision region type, and read sub-region membership through market.conditions.regions Condition.regions. Do not use deprecated market.regions as the source of truth for sub-region membership, because it may omit subdivision regions.

Sub-region Markets support shipping first. Other configurations including Discounts, Catalogs, Theme contextualization, Market metafields, are not yet supported. Unsupported API paths will return validation errors instead of allowing unsupported configurations.

Shipping apps can get more informtion in the dedicated shipping upgrade guide

OrderDisplayFulfillmentStatus now returns FULFILLMENT_NOT_REQUIRED for orders with no items to fulfill

As of API version 2026-10, the OrderDisplayFulfillmentStatus enum can return a new value: FULFILLMENT_NOT_REQUIRED. It is returned for orders that are not fulfilled but have no items remaining to fulfill — for example, an order that was fully cancelled or fully refunded before any items were fulfilled. Previously, these orders returned UNFULFILLED.

This is a backward-compatible, additive change: integrations that already handle unrecognized enum values gracefully don't need to do anything. As with all GraphQL enums, treat the set of values as open — new values may be added in future versions.

What's changing

• Order.displayFulfillmentStatus (and any field typed as OrderDisplayFulfillmentStatus) may return FULFILLMENT_NOT_REQUIRED on API version 2026-10 and later.
• This value represents an order whose remaining fulfillable quantity is zero — for example, all line item quantities were removed through order edits, or the order was closed by cancellation.
• API versions earlier than 2026-10 are unchanged and continue to return UNFULFILLED for these orders.

Why

The UNFULFILLED status was misleading for orders that have nothing left to fulfill. FULFILLMENT_NOT_REQUIRED makes the order's true state clear to merchants and to the apps that read it.

What you may need to do

• If your app exhaustively maps OrderDisplayFulfillmentStatus values (switch statements, status-to-label/badge maps, or generated types), add handling for FULFILLMENT_NOT_REQUIRED when you adopt 2026-10.
• If your app branches on or filters by UNFULFILLED, note that orders with no fulfillable items report FULFILLMENT_NOT_REQUIRED instead on 2026-10 and later.

New Features

Product variant intents

The React SDK added typed product variant intent hooks for selecting variants, adding variants to cart, and sending buyers to express checkout:

• useSelectVariant wraps select:shopify/ProductVariant.
• useAddToCart wraps add_to_cart:shopify/ProductVariant.
• useBuyNow wraps buy_now:shopify/ProductVariant.

These hooks can open the native Shop variant selector sheet over the Mini WebView when a Mini has a product ID but needs the buyer to pick a variant or quantity. Results distinguish successful actions, user dismissal, host errors, navigation to PDP, and referral-product handoffs.

Usage:

const { addToCart } = useAddToCart()
const result = await addToCart({ productId })
if (result.code === 'ok') {
  switch (result.data.outcome) {
    case 'added_to_cart':
      break
    case 'navigated_to_product':
      break
    case 'redirected_to_product':
      break
  }
}

Build verification during submit

The CLI now runs Minis build verification as part of submit. The verification system was also split into per-check orchestration with human-readable progress and JSON output support. Current checks cover dependency validation, ESLint disables, ESLint, TypeScript, build output, and manifest validation.

Scoped hook setup warnings

The CLI now warns when a Mini uses scoped SDK hooks before completing the required setup. This gives partners earlier feedback when code uses features that depend on declared scopes or account setup.

Documentation Updates

Intent resolution documentation

Docs were added or fixed for useResolveIntent, including examples that show returning typed intent results to Shop.

verify-build and submit documentation

The Shop Minis command docs now include verify-build, build verification usage, and how submit relates to build verification.

Product reviews documentation

Docs were added for useProductReviews, covering paginated review fetching by product ID.

Allowed dependency documentation

The allowed dependency docs were reconciled with CLI source and updated with newly allowed packages, including tw-animate-css.

Deprecations

usePopularProducts

usePopularProducts is deprecated and now emits a development warning. There is no one-to-one replacement. Use useRecommendedProducts for personalized discovery or useProductSearch for search-driven discovery.

Package Versions

Package Version

@shopify/shop-minis-platform 0.26.0
@shopify/shop-minis-react 0.28.0
@shopify/shop-minis-cli 0.3.21

Other Changes

• The allowed dependency set was expanded with newer partner-available packages, including tw-animate-css.
• Build verification now includes manifest validation and clearer per-check output.
• The Shop Minis CLI and docs were kept in sync for allowed dependency and build verification behavior.

Summary

May-June 2026 brings three net-new updates:

• Richer commerce actions through typed product variant intents and native variant selection.
• Stronger submission quality gates with build verification during submit.
• Clearer migration guidance through usePopularProducts deprecation messaging and updated docs.

For questions or feedback, reach out to the Shop Minis team.

Market-driven shipping moves merchant-owned shipping configuration out of delivery profiles and into Markets. Merchants will attach shipping options directly to each market, and then vary rates by product and location conditions within a single option. This makes checkout rate behavior more predictable and easier to understand.

What this means for your app:

• 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.
• 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.
• If your app reads, creates, or updates merchant shipping settings through the delivery profile API, you’ll need to update it. Market-driven shipping will start rolling out to merchants on October 1, 2026, and all merchants will be on it by July 1, 2027.

The feature preview is available today. Create a new development store, enable the feature preview, and validate your existing integration and rate logic.

To learn how market-driven shipping works and how to upgrade your app see Market-driven shipping feature preview.

As of the 2026-07 API version, draft order deposit fields are available in the GraphQL Admin API and Customer Account API.

Apps can now set a deposit when creating or updating a draft order with Draft Order Input.deposit in the GraphQL Admin API. This supports draft order flows where part of the payment is due at checkout and the remaining balance is due later, such as due-on-fulfillment payment terms.

The Customer Account API also exposes read-only deposit information on draft orders, including the amount due now and the amount due later.

This feature is available to Shopify Plus stores.

As of GraphQL Customer Account API version 2026-07, draft orders now expose discount applications.

You can use the new discount Applications field on DraftOrder to query discounts applied to a draft order, and the new discount Allocations field on Draft Order Line Item to query how discounts are allocated across line items.

For example:

query DraftOrderDiscounts($id: ID!) {
    draftOrder(id: $id) {
      discountApplications(first: 10) {
        nodes {
          __typename
          ... on DiscountCodeApplication {
            code
          }
          ... on ManualDiscountApplication {
            title
          }
          allocationMethod
          targetSelection
          targetType
          value {
            ... on MoneyV2 {
              amount
              currencyCode
            }
            ... on PricingPercentageValue {
              percentage
            }
          }
        }
      }
      lineItems(first: 10) {
        nodes {
          title
          discountAllocations {
            allocatedAmount {
              amount
              currencyCode
            }
            discountApplication {
              __typename
            }
          }
        }
      }
    }
  }

Use these fields to understand which discounts apply to a draft order and how those discounts affect individual draft order line items.

As of API version 2026-07, the BusinessEntity type in the GraphQL Admin API includes a new legalEntityId field. This field returns the stable Central Legal Entity ID from Shopify's Organizations Platform, giving Partners a consistent identifier for the same legal entity across multiple shops, markets, and sales channels.

What's new

The BusinessEntity type now includes:

• legalEntityId (BigInt, nullable): The stable organization-level legal entity identifier. This ID is consistent across all shops belonging to the same legal entity, enabling partners to recognize the same underlying company regardless of how many shops or markets it operates.

This field returns null when the business entity has no backing Central Legal Entity or when the legal entity does not have a stable external ID.

Example query

query {
  businessEntity(id: "gid://shopify/BusinessEntity/123456") {
    id
    legalEntityId
    companyName
    displayName
  }
}

Example response

{
  "data": {
    "businessEntity": {
      "id": "gid://shopify/BusinessEntity/123456",
      "legalEntityId": "223432432",
      "companyName": "Acme Corporation",
      "displayName": "Acme US"
    }
  }
}

Why this matters

Previously, BusinessEntity.id was scoped to individual shops, meaning the same company operating multiple shops would appear with different IDs. The new legalEntityId provides a single, stable identifier at the organization level that Partners can use to:

• Map a merchant's legal entity to a company code in their own systems
• Consistently identify the same company across multiple shops and markets
• Correlate legal entity data between the GraphQL Admin API and tax webhook payloads (where the same identifier appears as merchant_business_entity.legal_entity_id)

API version

This field is available starting in API version 2026-07 and in unstable.

We’re moving merchant-owned shipping configuration from legacy delivery profiles to Markets as part of market-driven shipping, a new model where shipping is configured per Market.

When a shop uses market-driven shipping, the legacy delivery profile fields and mutations in the Admin GraphQL API no longer represent the shop’s live merchant-owned shipping configuration. Reads may return a stale snapshot of the legacy configuration, and writes may succeed without errors but will not update the merchant’s live shipping settings.

This affects merchant-owned usage of the following Admin GraphQL delivery profile APIs:

• deliveryProfile
• deliveryProfiles
• deliveryProfilesCount
• deliveryProfileLocationGroup
• deliveryProfileLocationGroups
• deliveryProfileCreate
• deliveryProfileUpdate
• deliveryProfileRemove

App-owned delivery profiles aren’t affected and continue to function as before.

What to do

If your app currently reads or manages merchant-owned shipping configuration, you must follow the upgrade guide for market-driven shipping. The guide explains how to:

• Detect shops that are using market-driven shipping.
• Stop relying on merchant-owned delivery profile APIs for those shops.
• Migrate to Contextual Product Feeds, app-owned delivery profiles, or Markets APIs, depending on your use case.

Starting in API version 2026-07, the GraphQL Admin API supports market-driven shipping configuration. You can now configure shipping directly on a market, which helps apps support different shipping strategies for different markets without creating a separate shipping profile resource.

What changed

The Market object now includes a delivery field for market delivery settings. Use Market.delivery.shipping to read the shipping configuration for a market.

Use the existing marketCreate and marketUpdate mutations to create, update, or remove a market's shipping configuration:

• Use MarketCreateInput.delivery.shipping to add shipping configuration when creating a market.
• Use MarketUpdateInput.delivery.shipping to update shipping configuration on an existing market.
• Use MarketUpdateInput.delivery.removeShipping to remove a market-level shipping configuration so the market inherits shipping from its parent.

Shipping options are managed through DeliveryOptionDefinitionCreateInput and DeliveryOptionDefinitionUpdateInput. The API supports these option types:

• DeliveryFlatRateOptionDefinition for fixed-price shipping options.
• DeliveryValueBasedOptionDefinition for rates based on cart value.
• DeliveryWeightBasedOptionDefinition for rates based on package weight.
• DeliveryCarrierCalculatedOptionDefinition for rates calculated by carrier services.

Each shipping option includes fields such as currency and isActive. You can optionally configure a free delivery threshold with freeDeliveryMinimumValue. Flat and value-based options can include one or more rate groups. Weight-based options include exactly one weight-based rate group, and carrier-calculated options include a single carrier-calculated rate group.

What you can do

• Configure shipping options for a specific market.
• Offer different flat, value-based, weight-based, or carrier-calculated rates by market.
• Restrict rate groups to specific product collections or origin locations.
• Unconfigured markets naturally inherit shipping from their parents.
• Disable shipping for a market by setting isEnabled to false.

What you need to know

• Queries require read_markets access.
• Mutations require both read_markets and write_markets access.
• A null value for Market.delivery.shipping means the market inherits shipping from its parent. For markets without a parent, shipping inherits the shop default of no shipping.
• isEnabled: false means customers in that market will not see shipping options at checkout. This also disables any app managed shipping options that may otherwise apply to this market.
• There are no root queries or standalone mutations for market shipping configuration. Read and write shipping configuration through Market, marketCreate, and marketUpdate.

Example query

This query reads a market's shipping configuration, including whether shipping is enabled, how many active shipping options are configured, and the details for each flat-rate option.

Example mutation

This mutation updates an existing market with shipping enabled and adds a standard flat-rate shipping option with a fixed price and estimated transit time.

Example: Disable shipping for a market

Use isEnabled: false when the market should keep its market-level shipping configuration, but not show shipping options at checkout.

Example: Remove market-level shipping configuration

Use removeShipping: true when the market should inherit shipping from its parent instead of using its own shipping configuration.

Example: Add a value-based shipping option

This mutation creates a shipping option where the rate depends on cart value.

Example: Add a weight-based shipping option

Weight-based options uses a similar form but can only take a single rate group. The rate group can contain weight-based rates.

Example: Add a carrier-calculated shipping option

Carrier-calculated options also takes only a single rate group that references an existing carrier service.

Example: Update an existing flat-rate shipping option

Use optionDefinitionsToUpdate with the option ID. For flat-rate options, you can also update individual rate groups.

Example: Delete a shipping option

Use optionDefinitionsToDelete with the shipping option ID.

Related docs

Core objects and interfaces:

• Market
• Market Delivery Configurations
• Shipping Configuration
• Delivery Option Definition
• Delivery Flat Rate Option Definition
• Delivery Value Based Option Definition
• Delivery Weight Based Option Definition
• Delivery Carrier Calculated Option Definition

Rate groups, rates, and conditions:

• Delivery Option Definition Rate Group
• Delivery Flat Rate Group
• Delivery Value Based Rate Group
• Delivery Weight Based Rate Group
• Delivery Carrier Calculated Rate Group
• Delivery Rate
• Delivery Rate Group Conditions

Mutations and inputs:

• marketCreate
• marketUpdate
• MarketCreateInput
• MarketUpdateInput
• Market Delivery Configurations Create Input
• Market Delivery Configurations Update Input
• Shipping Configuration Create Input
• Shipping Configuration Update Input
• Delivery Option Definition Create Input
• Delivery Option Definition Update Input

The Hydrogen developer preview can now be deployed to Vercel in a few clicks. A new Deploy button creates a repo from the Next.js starter template, sets up a Vercel project, and builds it. No local setup required.

The template is a working Hydrogen storefront with the typed Storefront API client, cart, and product and collection pages already wired up. Add your store credentials from the Headless channel to connect your own products. You'll find it in the developer preview docs under "Deploy a starter template," alongside the setup paths for other frameworks and existing projects.