Shopify Release Notes

The release of Shopify CLI 4.0 today brings clarity to CLI versioning, the introduction of automatic updates, and the announced removal of the deprecated --force flag from shopify app deploy.

Semantic Versioning

Shopify CLI is now following semantic versioning practices. Releases with new features will be minor versions, and bug fixes will be patch versions. When required, major version releases will be used to communicate breaking changes to CLI command structure or behavior.

For more information, see our announcement of the move to SemVer.

Automatic Upgrades

Starting with Shopify CLI 4.0, Shopify CLI upgrades itself automatically using the package manager you installed it with. Auto-upgrade is skipped in CI, project-local installs, and for major version releases. Automatic upgrades can be disabled with the shopify config autoupgrade off command.

For more information, see Shopify CLI documentation.

Removal of the --force flag for app releases

The --force flag on the app deploy and app release commands didn’t distinguish between low-risk operations (adding or updating extensions) and high-risk ones (deleting them). This flag has been removed in Shopify CLI 4.0. The previously released --allow-updates and --allow-deletes flags give you granular control, so your CI/CD pipelines can run unattended without the risk of accidental, irreversible deletions.

For more information, see the March 2026 changelog.

Other removed commands and flags

The following deprecated commands and flags have also been removed in Shopify CLI 4.0:

• shopify webhook trigger (use shopify app webhook trigger)
• shopify theme serve (use shopify theme dev)
• shopify app generate schema (use shopify app function schema)
• shopify app webhook trigger --shared-secret (use --client-secret)
• shopify app generate extension --type (use --template)

Original source

Customer accounts are getting a visual refresh, featuring improved navigation, layout, and consistency across devices. You can preview these changes now and test your Shopify Extensions within the updated layout.

What's changing:

• Single-column native pages: These are now consistent across both desktop and mobile, with simplified navigation. Inline extensions will render in a narrower page width compared to the previous wider layout. Full-page extensions can either adopt our mobile-first, narrow layout that matches native pages or expand to a wider layout for data-heavy content.
• Increased visibility for order action extensions: Order action extensions are now more visible, and order summary extensions are no longer hidden behind a tap on mobile devices. This change makes it easier for customers to discover and use the features you've built.
• Existing extension targets are mapped to the new layout: Ensuring compatibility with the new design. See extension targets by page.

All current extension targets remain supported. However, this is an ideal time to review them. Testing now gives you a head start on any adjustments needed to ensure your extensions integrate seamlessly before these design updates are released to merchants. The feature preview will be available until June 12, 2026.

Read our documentation to start the preview. You can ask questions and share feedback in the Shopify community.

Original source

New Features

Optional Consent

Users can now reject scopes and continue using your Mini. Consent is no longer all-or-nothing — if a user declines a scope, your Mini should gracefully degrade rather than block the experience. If your Mini hard-fails when a scope is rejected, please update it using the new hooks below.

useCheckScopesConsent Hook

Check at runtime which scopes a user has granted. Use this to conditionally render features that depend on a particular scope.

Usage:

import {useCheckScopesConsent} from '@shopify/shop-minis-react'

function MyMini() {
  const {scopes} = useCheckScopesConsent()

  if (scopes.includes('product_lists:write')) {
    return <SaveToListButton />
  }
  return <SignInPrompt />
}

useRequestScopesConsent Hook

Re-request consent after a user has previously declined. The hook must be invoked from a user interaction — you cannot re-prompt automatically. Use this for flows where granting consent unlocks a clear, user-initiated action.

Usage:

import {useRequestScopesConsent} from '@shopify/shop-minis-react'

function GrantAccessButton() {
  const {requestScopesConsent} = useRequestScopesConsent()

  return (
    <button onClick={() => requestScopesConsent(['product_lists:write'])}>
      Enable saving products
    </button>
  )
}

useCheckPermissions Hook

Separate from scopes, useCheckPermissions lets your Mini check OS-level permissions (camera, photo library, and so on) before invoking an action that requires them.

Usage:

import {useCheckPermissions} from '@shopify/shop-minis-react'

function CameraFeature() {
  const {permissions} = useCheckPermissions(['camera'])

  if (permissions.camera === 'granted') {
    return <CameraView />
  }
  return <RequestCameraButton />
}

request_blocked Sentinel

When a user has declined a scope or permission and the platform will not re-prompt, the relevant hooks now return a request_blocked sentinel value instead of null. This lets you distinguish "not asked yet" from "asked and blocked" and tailor your UI accordingly. See the Scopes Consent docs on shopify.dev for the full state machine.

Intents

Intents are a new communication layer between the Shop app and Shop Minis. The Shop app launches your Mini from contextually relevant moments — such as a product detail page — and passes along the context (typically a product). For partners, this opens a new path to distribution: instead of relying on the Explore tab alone, your Mini can be surfaced where buyer intent is highest.

Two intents are supported today:

Intent What it's for try_on Virtual try-on Minis — clothing, accessories, anything wearable view_in AR and room-placement Minis — furniture, decor, anything you'd visualize in a space

If your Mini fits one of the supported intents, or you have a different use case in mind (recipe building, gift finding, custom configurations, and so on), reach out to the Shop Minis team — we're onboarding partners now and actively scoping new intents.

useIntent Hook

Parse the intent that launched your Mini. Use this to read the context the Shop app passed in and route the user to the right experience.

Usage:

import {useIntent} from '@shopify/shop-minis-react'

function MyMini() {
  const intent = useIntent()

  if (intent?.action === 'try_on') {
    return <TryOn productId={intent.productId} />
  }
  return <DefaultExperience />
}

Async Storage Limits

To keep Minis fast, we're introducing limits on useAsyncStorage and useSecureStorage:

• 10 keys max per Mini
• 1 MB per key

Most Minis are well under both limits. Async storage is intended for small structured data — if you're persisting larger assets like images, use a dedicated upload hook and store the resulting URL instead of the raw bytes.

availableForSale on Product Hooks

Product hooks now expose availableForSale on variants, and the SDK's commerce buttons (AddToCartButton, BuyNowButton) handle the out-of-stock state out of the box. If you render product cards or build a custom commerce flow, check availableForSale before letting users add to cart.

pnpm Support in the CLI

npx minis create now detects and supports pnpm alongside npm and yarn.

Usage:

npx minis create
# Select pnpm when prompted

Documentation Updates

Scopes Consent

The Scopes Consent page on shopify.dev has been updated to reflect optional consent. It now documents the full state machine (granted, declined, request_blocked) and includes guidance for the new useCheckScopesConsent, useRequestScopesConsent, and useCheckPermissions hooks.

Intents

A new documentation page covers intents end-to-end: what they are, which intents are supported today (try_on, view_in), the launch-context contract, and how to parse the intent in your Mini with the useIntent hook.

Deprecations

localStorage and sessionStorage

Browser storage is no longer permitted inside the Mini webview — it's disabled on Android and reset between sessions on iOS. The Shop Minis ESLint config now flags any use of localStorage or sessionStorage. Migrate to useAsyncStorage (persistent) or useSecureStorage (encrypted).

Package Versions

Package Version @shopify/shop-minis-platform 0.17.0 @shopify/shop-minis-react 0.20.0 @shopify/shop-minis-cli 0.3.11

Other Changes

• Phantom dependency imports blocked: The partner ESLint config flags imports of packages not declared in your package.json.
• Transitive SDK deps allowed: clsx, tailwind-merge, and cva are now explicitly available for partner use.
• TypeScript 6: The SDK is now built against TypeScript 6.0.2 (up from 5.8.3).

Summary

March-April 2026 brings significant improvements to the Shop Minis platform:

• Optional consent is now the default — three new hooks let your Mini gracefully degrade when scopes are declined.
• Intents are a new communication layer for launching your Mini from contextually relevant moments in the Shop app — try_on and view_in supported today.
• Async storage limits of 10 keys per Mini, 1 MB per key.
• availableForSale on product variants for first-class out-of-stock handling.
• localStorage and sessionStorage are no longer permitted in the Mini webview.

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

Original source

We're changing how public apps handle offline access tokens to enhance merchant data protection. Starting January 1, 2027, all public apps must use expiring offline access tokens when calling the Admin API. After that date, public apps still using non-expiring tokens will receive authentication errors.

This extends the April 1, 2026 change, which applied only to newly created public apps, to all public apps, including those created before April 1, 2026.

What apps are affected

Public apps making Admin API requests using non-expiring offline access tokens, including apps created before April 1, 2026

What apps are unaffected

• Custom apps
• Apps created by merchants either in the Dev Dashboard or in the admin

Why we're making this change

Non-expiring tokens, if leaked, remain valid indefinitely. Expiring tokens close that window in 60 minutes and rotate automatically, dramatically reducing the impact of a credential leak. This aligns with modern OAuth best practices, and as a developer it gives your app a predictable refresh flow.

Action required

Existing public apps: Migrate from non-expiring to expiring offline access tokens.

Merchants don't need to reinstall, as your app exchanges existing tokens through code. Follow the migration guide for the step-by-step path. If you use Shopify's app templates and official API libraries, refresh handling is already implemented; you only need to handle the token exchange and storage updates.

Need help? Engage with the dev platform community for support and questions.

Original source

Next Generation Events are now available in developer preview, with field-level control over when events fire, what data they carry, and what triggered each delivery.

Subscribe to exactly what you care about

Field-level triggers pre-qualify deliveries before they reach your endpoint. A subscription scoped to product.variants.price won't fire on title edits, tag updates, or status changes. Only when the price changes.

Get the payload your app needs, not a fixed schema

You define the delivery payload with a standard Admin GraphQL query. No over-fetching fields you'll discard. No extra API call to get the data you actually wanted after the webhook lands.

Know what fired for each delivery

Every delivery includes fields_changed: an explicit list of the fields that triggered the event, with full entity paths and IDs. That means you don't need to infer, or diff against prior state.

Filter on current state

query_filter narrows deliveries based on the current state of your query output. Use it to skip events that don't meet your conditions, like only delivering for active products.

Configure in code

Subscriptions live in shopify.app.toml alongside your other app configuration. Version-controlled, reviewable, and deployable.

As a developer preview, Events are available in the unstable API version and APIs may change. Product and Customer topics are live today.

Configuration and payload

[events]
api_version = "unstable"

[[events.subscription]]
handle = "price_sync"
topic = "Product"
actions = ["update"]
triggers = ["product.variants.price", "product.variants.compareAtPrice"]

uri = "/api/events"

query = """
	query priceSync($productId: ID!, $variantsId: ID!) {
		productVariant(id: $variantsId) {
			id
			price
			compareAtPrice
			sku
		}
		product(id: $productId) {
			id
			title
			status
		}
	}
"""
query_filter = "product.status:'ACTIVE'"

Every delivery includes fields_changed, data from your query, and query_variables used to fetch it:

{
  "topic": "Product",
  "action": "update",
  "handle": "price_sync",
  "data": {
    "productVariant": {
      "id": "gid://shopify/ProductVariant/456",
      "price": "24.99",
      "compareAtPrice": "34.99",
      "sku": "SIGNAL-NOT-NOISE"
    },
    "product": {
      "id": "gid://shopify/Product/123",
      "title": "Peace & Quiet Tee",
      "status": "ACTIVE"
    }
  },
  "fields_changed": [
    "product[id: 'gid://shopify/Product/123'].variants[id: 'gid://shopify/ProductVariant/456'].price"
  ],
  "query_variables": {
    "productId": "gid://shopify/Product/123",
    "variantsId": "gid://shopify/ProductVariant/456"
  }
}

Learn more

Learn more about how Events relate to Webhooks: Get started by Creating an Events subscription.

Original source

You can query the shipping Line field on Fulfillment Order Line Item

This field returns the Shipping Line associated with a fulfillment order line item, if available. This feature simplifies the process for order management and fulfillment apps to identify the shipping method for each line item. It is particularly useful in scenarios where fulfillment orders are merged across different delivery profiles, and the original per-line shipping service is not identified by the fulfillment order's delivery method.

For example, apps can use properties such as shipping Line.code, shipping Line.title, and shipping Line.source to accurately map line items to the correct carrier service or shipping method.

For more information, refer to the Fulfillment Order Line Item reference.

Original source

What's Changed

You no longer need to ask merchants to share function run logs with you. These logs are now automatically available in the Dev Dashboard for any function your app has the necessary access scopes to view.

Function run logs in the Dev Dashboard are now accessible based on the access scopes granted to your app by the merchant. The required scopes to view a log are determined by the function's input query. If your app has the necessary scopes to read these fields via the GraphQL Admin API, you will automatically see the run details without needing any additional action from the merchant.

What You Need to Do

If you expect to see function run details but don't, ensure your app has the scopes required by the input query. Here's how you can check:

• Request the scopes during your app's installation/authentication process: This is ideal for scopes your app consistently needs. Refer to Access scopes for instructions on declaring and requesting access scopes.
• Request protected customer data scopes when accessing customer data: Some fields, like customer details and addresses, require additional protected customer data access. Consult Protected customer data for the approval process and necessary data-level scopes.
• Use optional scopes for temporary or debugging access: If a scope is needed occasionally, such as for debugging, request it as an optional scope. Merchants can grant or revoke it without reinstalling the app.

Once the required scopes are granted, the run details will automatically be visible the next time you access the log.

Original source