Shopify Developers Updates & Release Notes

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.

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.

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

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.

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.

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.

Product Variant is now a Publishable. Variants can be published or unpublished per publication (channel or catalog) in API version 2026-07, giving merchants — and your apps — fine-grained control over where each variant is visible without deleting variants, duplicating products, or hiding them via storefront code.

This is a non-breaking, additive change:

• Product-level publishing is unchanged and still takes precedence. A product must be active and published to a channel for any of its variants to render there.
• Variants default to published (opt-out model). Existing apps that publish at the product level continue to work without modification.
• Variants can be created in an unpublished state in order to prevent early exposure to buyers.

What's new in the Admin GraphQL API

• publishablePublish and publishableUnpublish now accept ProductVariant IDs.
• ProductVariant now adheres to the Publishable interface, similar to Product and Collection, which includes resourcePublicationv2 and publishedOnPublication.
• Product feed webhooks fire with a product update for variant added and deleted when variants are published to the feed’s channel.
• variant_publication/create/update/delete webhooks are still under development and will be shipped imminently.

What this means for your app

• Channel apps using product feeds should not require any changes to work - the product feed adds and removes variants to the product and an incremental sync webhook is triggered.
• Channels or pseudo channels that do not use product feeds and rely on reading publication state via the admin graphql API should implement support by reading the respective publication state of variants via ProductVariant.resourcePublicationsv2.
• Apps that create variants after product publication occurs: new variants default to published in all of the parent product's publications. If your app plans to create variants in an unpublished state, productSet and productVariantBulkCreate both include a variant.published: false field to create variants as unpublished.
• Apps that publish products: no changes required. Continue calling publishablePublish on products as before. Consider implementing variant publishing support if unpublishing variants is relevant to your apps workflows.

Read the developer guide →

We've introduced markets as a new option in DiscountContextInput, enabling you to target discounts to specific regional markets, retail locations, or B2B company locations. This option can be used alongside existing eligibility options such as all, customerSegments, and customers.

You can now set market eligibility for all discount types, including:

• Basic, BXGY, App, and Free Shipping discounts (both automatic and code-based).
• Note that eligibility types are mutually exclusive—you can target either markets OR customer segments, but not both simultaneously.

What you can do

• Assign market eligibility to a discount by using markets in DiscountContextInput when creating or updating a discount.
• Query the discounts and discountsCount fields on a Market to view the list of discount customizations for that market.
• Filter discounts by any market eligibility using context:market or by specific markets using market_ids in discountNodes.

What you need to know

• Discounts do not inherit across different market types (e.g., from regional to B2B or retail). When you assign a discount to a regional market, it automatically applies to sub-markets of the same type (e.g., from "North America" to "Canada").
• If you are using API versions prior to 2026-07, discounts with market eligibility will be filtered out, as these versions cannot represent them (both in node queries and specific discounts by ID).

For more information, refer to the Admin GraphQL API documentation.

App deployment in CI/CD is now available for all apps through app automation tokens on the Dev Dashboard. These tokens offer app-scoped authentication, allowing you to use the latest Shopify CLI to automate app releases in GitHub Workflows and similar tools. App-scoped authentication ensures that each token is specific to an individual app, enhancing security and control.

To deploy your app using an app automation token, set the token as an environment variable and execute the deployment command:

export SHOPIFY_APP_AUTOMATION_TOKEN="your-app-automation-token"
shopify app deploy --config production --allow-updates

App automation tokens replace the CLI tokens previously generated on the Partner Dashboard. While existing CLI tokens will remain functional until they expire, transitioning to app automation tokens is recommended for enhanced security and functionality. Learn more about migrating to app automation tokens.

For further information on app automation tokens, visit Shopify.dev:

• Managing app automation tokens
• Deploy app components in a CD pipeline

Shopify Plus and Enterprise merchants will soon be able to enable a single checkout experience where customers can choose both shipping and store pickup within the same order. Previously, customers had to place separate orders for each delivery method.

This change impacts how delivery and fulfillment information flows through checkout. If your app reads, calculates, or displays delivery and fulfillment information, the testing window is open now. Enable feature preview and make the necessary updates before this rolls out to merchants.

Apps that have not been updated may cause checkout errors, incorrect calculations, or failed fulfillment routing, impacting the merchant's checkout experience.

What changed

When a merchant has both shipping and local pickup enabled, customers can now choose between store pickup or shipping for each item in their cart during checkout. This creates a single order with multiple fulfillment orders: one for shipping, one for pickup.

There are no new API fields or breaking schema changes. However, existing API fields now return data in new combinations:

• Checkouts can have multiple deliveryGroups: each group represents how different items are to be fulfilled.
• Orders can contain fulfillment orders with different delivery methods (SHIPPING and PICK_UP) within the same order.
• Fulfillment orders include a delivery_method field that identifies the fulfillment method for each group.

What you need to do

• Review the testing guide.
• Audit your app's assumptions. Identify any logic that assumes a single delivery method per order.
• Test your app in feature preview:
  • Go to "Dev stores" and create a dev store.
  • Make sure to select "Plus" under Shopify Plan and "Ship and pickup" under Test a feature preview on this store.
• Verify your app handles the order correctly end-to-end:
  • Place a test order with both shipped and pickup items.
  • Ensure your app reads the delivery_method field on fulfillment orders and routes items accordingly.
• If your app update changes merchant-facing behavior or workflows, communicate those changes to your merchants as soon as possible.

Visit the developer forum for questions and updates.

Seven new Settings intents let apps open editors for notifications, payment capture, gift cards, delivery profiles, and business details. This builds on the initial Settings intents release from March.

With a single API call, your app opens the relevant Settings section as a contextual overlay and scrolls the merchant directly to the field they need to edit.

New intents

Notifications

• edit:settings/Notifications Sender Email
• edit:settings/Notifications Staff

Payments and gift cards

• edit:settings/Payment Capture Method
• edit:settings/Gift Card Expiration

Delivery

• create:shopify/Delivery Profile
• edit:shopify/Delivery Profile

Business

• edit:settings/Business Details

Each intent opens the relevant Settings page in a page stack and scrolls the merchant directly to the targeted card, following the pattern established in the initial release.

Resources

• Read up on admin intents
• Learn more about supported Shopify resources
• Leave us feedback in the Shopify Developer Community

Inventory transfer webhooks: new origin and destination fields

Payloads for the following webhook topics now include the source and destination location of the transfer as Location Global IDs:

• inventory_transfers/add_items
• inventory_transfers/update_item_quantities
• inventory_transfers/remove_items
• inventory_transfers/ready_to_ship
• inventory_transfers/cancel
• inventory_transfers/complete

Each payload now includes:

• origin.id — for example, gid://shopify/Location/123
• destination.id — for example, gid://shopify/Location/456

You can use these IDs to identify where inventory is moving without making an additional API call to fetch the transfer.

The new fields are scoped to subscriptions whose webhook API version includes this change. If your subscription is on an earlier version, or the transfer's source or destination is not a Location (for example, a supplier-fulfilled transfer), the keys are omitted from the payload entirely rather than returned as null.

Available now on the unstable API version. See the Inventory transfer webhook reference for details.

Clarified documentation for inventoryTransferSetItems

We've updated the description on inventoryTransferSetItems to better describe how it actually behaves. The behavior itself has not changed.

• inventoryTransferSetItems is an upsert. Only the inventory items you include in lineItems are affected; line items already on the transfer that you don't reference are left unchanged. Each inventoryItemId may appear at most once per call.
• On a READY_TO_SHIP or IN_PROGRESS transfer, the quantity you pass replaces only the processableQuantity; already-shipped or picked quantity is preserved, and the resulting total is the preserved portion plus the provided quantity.
• quantity: 0 is only valid on DRAFT transfers, where it leaves a zero-quantity line item on the transfer. To remove a line item, use inventoryTransferRemoveItems. On READY_TO_SHIP or IN_PROGRESS transfers, 0 returns an INVALID_QUANTITY error.

Clarified documentation for inventoryTransferRemoveItems

We've also updated the description on inventoryTransferRemoveItems to better describe its behavior:

• The mutation can be called on transfers in DRAFT or READY_TO_SHIP status.
• For each line item you reference, if its full quantity is still unallocated to a shipment, the line item is removed; otherwise the line item remains on the transfer with its quantity reduced to the allocated portion. Quantity allocated to a shipment — whether the shipment is still a draft, in transit, or already received — is preserved.
• On READY_TO_SHIP transfers, removing items returns the affected reserved quantity to available inventory at the origin location.
• Passing an omitted or empty transferLineItemIds is now treated as a no-op and returns the transfer unchanged.
• To change the quantity of a line item without removing it, use inventoryTransferSetItems.

Clearer error messages on inventory transfer mutations

Several user errors returned by the inventory transfer mutations now have more descriptive messages so that you can act on them without consulting additional docs:

• READY_TO_SHIP_TRANSFER_REQUIRES_AT_LEAST_ONE_ITEM — now explains that you cannot remove every line item from a READY_TO_SHIP transfer and that, to empty one, you should cancel it instead.
• ITEM_FULLY_SHIPPED — now clarifies that the check fires when the full quantity of the item is allocated to one or more shipments (including draft shipments where the item has been picked), and that the error name refers to the underlying allocation check rather than physical shipment.
• ITEM_PRESENT_ON_DRAFT_SHIPMENT_WITH_ZERO_QUANTITY — now states plainly that the line item appears on a draft shipment with quantity 0.

Error codes themselves are unchanged, so existing handling in your apps continues to work.

The default value of appliesOnSubscription has been changed from false to true on the Discount Code App Input and Discount Automatic App Input input types in GraphQL Admin API.

No action is required. This default value change has no effect on how discounts are applied at checkout. If your app explicitly sets appliesOnSubscription when creating or updating app discounts, your behavior is unchanged.

This change applies across all active API versions. The appliesOnOneTimePurchase field already defaults to true and is unchanged.