Shopify Developers Updates & 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

As of version 2026-07 of the GraphQL Storefront API, the Cart object issues a warning when a buyer's selected delivery option becomes unavailable.

Previously, if a buyer's chosen delivery option was no longer available (for example, after changes to the cart's address or contents) the system would automatically switch to a different option without notifying the buyer. This lack of notification made it challenging for developers to inform buyers of the change.

Now, with the introduction of the DELIVERY_SELECTED_OPTION_NOT_AVAILABLE value in the Cart Warning, developers can programmatically detect when a selected delivery option is unavailable. This allows you to prompt buyers to confirm or choose a new delivery option, ensuring they are aware of any changes.

Original source

As of API version 2026-04, the new Checkout And Accounts Configuration API is now available to unlock consistent branding customizations across checkout, customer accounts, and sign-in surfaces. This API is exclusively available to Shopify Plus merchants.

This new API replaces the Checkout Profile API and Checkout Branding API (both are now deprecated). All capabilities to customize settings and branding for checkout, and customer accounts, and sign-in are now consolidated into one single API.

What you can do:

• Shared branding settings: Use shared designTokens and components to set branding once and apply consistently across checkout, customer accounts, and sign-in pages. Section styles (padding, shadows, colors, borders, and border radius) previously available for checkout only can now be applied to customer account pages.

• Surface-specific overrides: Apply targeted overrides under surfaces.checkout, surfaces.customerAccounts, and surfaces.signIn for logos, colors, and section styles.

• Direct color settings: Set color using HEX values or palette colors directly on sections like main, header, and orderSummary — no more mapping through a limited number of color schemes. Save your brand colors to an editable color palette of up to 20 colors and reference anywhere you make a color selection. Update a palette color, and it changes everywhere it is referenced.

• Customize branding per market: Customize your pages for each market with unique branding settings.

View developer documentation for more detail.

Original source

We’ve published new migration guides to help you upgrade Checkout and Customer Account UI extensions to the latest API version and Polaris web components.

The new guides include:

• Guidance for moving from React or JavaScript extension APIs to Preact, Polaris web components, and the global shopify object.
• More than 60 component-specific migration pages, covering components such as Button, Checkbox, Text Field, Banner and View for Checkout and Customer Account UI extensions.
• Instructions for migrating checkout metafields to cart metafields

If your extension uses an API version earlier than 2025-10, use these guides to adopt Polaris web components, which are the default in API version 2025-10 and later.

Start with:

• Checkout UI extensions migration guide
• Customer Account UI extensions migration guide

Original source

The App Events API lets you send any event from your app to Shopify. App event data appears in your Dev Dashboard Logs alongside webhooks, Function executions, and API calls.

How it works:

1. Send app events to a single API endpoint: Define the event_handle and attributes you want to track and send them to the App Events API, including:

   • Feature usage: bulk_edit_completed, report_generated, automation_created
   • Workflows: onboarding_completed, campaign_sent, export_finished
   • Performance: sync_failed, api_timeout, rate_limit_hit
   • Conversion signals: limit_hit, premium_viewed, milestone_achieved
   • Billable activities: order_processed, email_sent, label_printed

2. View events in Dev Dashboard: All app events flow into Dev Dashboard Logs automatically for monitoring, alongside data Shopify provides about your app, i.e: Webhooks, Functions executions, and API calls.

3. Optional: Turn app events into billing: On Shopify App Pricing, any app event can become a usage-based charge. Define a meter in the Partner Dashboard, match it to an event_handle, and Shopify handles metering and invoicing. No additional code required.

App Events is available now for all apps, regardless of billing method.

Original source

What's new:

Managed Pricing is now Shopify App Pricing

Shopify App Pricing replaces Managed Pricing as Shopify’s default billing solution that gets configured during app submission in the Partner Dashboard. Apps previously on Managed Pricing will now see “Shopify App Pricing” as their selected billing solution.

Usage-based billing now possible with App Events API

Charge based on merchant usage using the App Events API. Send events from your app, define meters in the Partner Dashboard, and Shopify handles aggregation, calculation, and invoicing. Three pricing structures supported: fixed, graduated, and volume. Supports negative reporting for automatic charge corrections.

New APIs make billing data more accurate

Active Subscription API: Real-time subscription status (active, pending, cancelled, frozen) that persists beyond uninstall
Historical API: Full event log of installs, uninstalls, subscription changes, charges, credits, and usage

Transparent billing in the admin

Merchants see a billing card on the app settings page in the Shopify admin that displays their current plan, subscription status, usage charges, and upcoming pricing changes — including downgrades. This is the same information surfaced through the Active Subscription API.

Billing API marked as legacy

The Billing API continues to function but is now legacy. All apps should use Shopify App Pricing going forward.

What this means for your billing:

• Apps with no active charges: Shopify App Pricing is the default. Configure pricing during app submission. [Learn more]
• Existing apps with active charges on Managed Pricing or Billing API: Your current billing continues without changes. Migration tooling will be available soon to support the transition to Shopify App Pricing. Learn more.

App Events API:

Available now for all apps. Read the dev docs to get started.

Original source

Shopify now applies stricter rate limits to bots and agents that access the Storefront API and Shopify-hosted online store pages. Bots and agents that don't sign their requests are subject to the strictest limits. To qualify for higher rate limits, operators should sign their requests with Web Bot Auth. For more details, see Storefront rate limits.

What you should do

If you operate a bot or agent accessing Shopify storefronts, sign your requests using Web Bot Auth. To get started, review the Web Bot Auth architecture and Cloudflare's implementation guide — for context only, you do not need to enroll with Cloudflare.

Higher access tiers

If you require higher rate limits than those provided to Web Bot Auth traffic, please contact us through this form.

Shopify Merchants

Shopify merchants who want to crawl their own stores can find ready-to-use Web Bot Auth signatures in the Shopify admin.

Original source