Shopify Developers Updates & Release Notes

The shop_campaign_insights schema is now available in the ShopifyQL. Analytics and reporting apps can query Shop Campaigns performance data on behalf of authorized merchants using the existing shopifyql Query field with read_reports scope.

Available data

Campaign-level and segment-level metrics including ad spend, sales, orders, ROAS, average order value, and average customer acquisition cost. Data is available by campaign name, customer segment, and time dimensions from hourly to yearly in the merchant's shop timezone.

How to get started

Query shop_campaign_insights using the same shopifyql Query field you use for other ShopifyQL schemas. No new scopes or integration work required if you already query ShopifyQL.

• Schema reference: shop_campaign_insights
• Building with ShopifyQL
• ShopifyQL API reference

Also new: Analytics Web Components let you embed Shop Campaigns metrics directly in your app UI using with no data storage required. The Analytics Annotations API lets you create annotations on merchant analytics charts (e.g., "campaign started," "budget changed").

The update Cart standard action now updates cart attributes, and a new shopify:cart:attributes-update event fires whenever an attributes update is initiated.

Before this, changing an attribute meant calling the Storefront API yourself, and nothing told your app when one changed. The action now handles attributes like any other cart update, and the event fires whether your app, the theme, or another app made the change. It carries the full new set of attributes and a promise for the result, so you can update your UI right away and roll it back if the cart declines the change.

Learn more in the event reference and the updated update Cart reference.

Online stores now expose WebMCP tools that AI agents can call. Agents can search your catalog, manage the shopper's cart, and go to checkout on the shopper's behalf, all in the tab they're looking at.

The tools work through WebMCP, a proposed web standard that lets a page register tools with the browser. Without it, agents have to read every page's code and simulate clicks, which is slow and error-prone. The tools are live today on every Liquid storefront and on the Hydrogen developer preview. There's nothing to install or configure.

Everything an agent does happens on the shopper's live session. Cart tools call the same standard storefront actions that apps use, so if your theme opens a cart drawer on updates, agents trigger it too.

Here's what agents can call:

• Catalog: search_catalog, browse_store, get_product, and show_variant
• Cart: get_cart, update_cart, and cancel_cart
• Checkout and orders: proceed_to_checkout and manage_orders
• Other content: search_shop_policies_and_faqs

WebMCP is still an emerging standard, and agent support is currently limited to Chromium-based browsers through an origin trial. Shopify is helping shape the specification alongside Google and Microsoft.

Learn more in the WebMCP docs. If you're building your own agent, see Build commerce agents.

We’ve added a trackingNumbers field to OrderCreateFulfillmentInput, so you can attach multiple tracking numbers to a fulfillment when importing orders.

If you use the orderCreate mutation to import orders that ship in more than one package, you no longer need to update the fulfillment after creation to add additional tracking numbers. Instead, you can include all tracking numbers upfront when you create the order.

Use the trackingNumbers field to pass an array of tracking number strings, for example:

trackingNumbers: ["1Z999AA10123456784", "1Z999AA10123456785"]

The trackingCompany value you provide applies to every tracking number in the array. This behavior is consistent with how FulfillmentTrackingInput already works on the fulfillmentCreate mutation.

If you provide both the singular trackingNumber and the plural trackingNumbers, the singular value takes precedence. In that case, the value of trackingNumber is used and trackingNumbers is ignored. This ensures that your existing integrations continue to work without any changes.

This field is available starting in API version 2026-10.

Learn more

• orderCreate mutation reference
• OrderCreateFulfillmentInput
• Manage fulfillments

We've updated three Built for Shopify requirements for Fulfillment services apps. The updated thresholds better reflect how fulfillment operations run in practice, making Built for Shopify achievable for more high-quality fulfillment apps. No action is required.

What changed

• 5.8.2 Complete fulfillment orders: adjusted the required completion rate for assigned fulfillment orders.
• 5.8.6 Respond to fulfillment requests: extended the response window and adjusted the required response rate.
• 5.8.7 Respond to cancellation requests: extended the response window.

How these criteria are measured is otherwise unchanged. The requirements page linked above lists the current thresholds.

Who's affected

Apps in the Fulfillment services category, such as third-party logistics and warehousing apps, that hold or are working toward Built for Shopify status. Apps in other categories aren't affected, and no other Built for Shopify requirements have changed.

What to do

No action is required. Built for Shopify status is evaluated automatically against these criteria. If your fulfillment app previously fell short of these requirements, you may now qualify.

Related docs

• Build for fulfillment services
• Built for Shopify overview

New fields are now available on cash management resources in the GraphQL Admin API, providing more detail about cash drawer balances and cash count activities.

What's new

Cash Drawer balance

The Cash Drawer object now exposes the current drawer balance directly:

Field | Description
balance | The current balance in the cash drawer, returned as a Money V2 value.

Cash count activity details

Cash Count Activity now includes additional context about opening and closing counts:

Field | Description
note | A note associated with the activity, such as a comment left by staff during a cash count.
reason Code | The reason code for the activity, connecting counts to merchant-defined categorization.

Learn more

• New retail cash management capabilities (2026-04)

The Hydrogen developer preview adds new capabilities to the toolkit and extends the ways developers can build Shopify storefronts:

• Vue bindings: Build your storefront in Vue with the same Hydrogen APIs you know from React, through the new @shopify/hydrogen/vue entrypoint.
• GraphQL TypeScript tooling: Query autocomplete and type checking for both Shopify APIs now ship with the package.
• Analytics and consent through ShopifyScripts: Storefront analytics and consent management now set up with the rest of your Shopify scripts, including support for Shopify's privacy banner.
• Shopify Inbox support: Shoppers can chat with your store's AI agent and get handed off to your staff, right from your Hydrogen storefront.
• Suspense cart reads in React: The cart can stream in after the page renders, so your app shell stays fast and cacheable.

To get started, visit the Hydrogen developer preview documentation. For a detailed breakdown of this release, read the full release notes.

In February 2026, we introduced the shopify-account component, which lets customers sign in and manage their account directly on the storefront. It supports passwordless sign-in, automatic Sign in with Shop recognition, and social sign-in providers. Once signed in, customers can reach their account pages from the account menu.

As of today, all new themes and updates to existing themes submitted to the Shopify Theme Store must include the component in their header, visible on both desktop and mobile, so customers get a consistent experience on any device.

Additionally, legacy customer accounts have been deprecated, and themes are no longer required to include legacy customer account template files.

Learn more:

• shopify-account component developer docs
• Theme store requirements — features
• Legacy customer accounts are deprecated

What changed

Collaborator access is built on trust. When a merchant approves a request, they're giving a partner access to a live store — and merchants need enough context to make that decision with confidence. Building on identity verification for partners, merchants now see details about your partner organization on every new collaborator request. Here's what partners need to know.

When you send a collaborator request, merchants will see details about your partner organization directly in the request — both in the Shopify admin and in the collaborator request email. These details include:

• How long your partner organization has been on Shopify
• The country where your partner account was registered
• The country the request was sent from
• An approximate range of merchant stores your organization is actively collaborating with

These details are generated automatically from your partner organization's account and activity — there's nothing to fill out, configure, or maintain. The active collaborations count only includes merchant stores on a paid plan, so development stores don't affect it.

If your organization is newer to Shopify, merchants will see that too. That’s not a penalty — it’s context. Every partner starts somewhere, and a clear, specific request goes a long way while your track record is still growing.

This change only applies to new collaborator requests. Requests that merchants have already accepted aren't affected.

Why this matters

Previously, merchants reviewing a collaborator request had little to go on beyond the partner's name and message. Some bad actors are trying to exploit that gap and social-engineer their way into real merchant stores using collaborator accounts. That hurts merchants directly, and it creates an uneven playing field for partners who do great work.

Showing verifiable details on every request gives merchants meaningful signal before they grant access — and lets your track record speak for itself.

What to do

Nothing is required to enable this feature — these details appear automatically, and there's nothing to fill out or maintain. However, as you send collaborator requests, the following practices will help merchants say yes with confidence:

• Complete identity verification in your Dev Dashboard if you haven't already. Learn more here.
• Write a clear, specific request that explains who you are, what you'll be working on, and why you need access.
• Request only the permissions you need. Narrow, well-scoped requests are easier for merchants to review and approve.

Collaborator requests should be an easy yes for merchants working with trustworthy partners. These changes are designed to help you demonstrate that trust and make approvals more straightforward.

Related docs

• Collaborator requests: Information shared with merchants

Shopify Functions API version 2026-10 adds a createdAt field to the Customer object. You can now use the date and time a customer account was created in Function logic. This is an additive change; no action is required for existing Functions.

What changed

The Customer object now exposes createdAt, which returns the date and time when the customer account was created. This lets you build customizations based on when a customer joined.

To use createdAt, request it from the customer on Cart.buyerIdentity in the Function input query:

query
Input {
  cart {
    buyerIdentity {
      customer {
        createdAt
      }
    }
  }
}

The customer is available only when the buyer is signed in. Functions should continue to handle guest buyers, where buyerIdentity or customer might be null or omitted.

Earlier Shopify Functions API versions are unchanged. To use the new field:

• Update the Function to API version 2026-10.
• Add createdAt to the Function’s input query.
• Test with both signed-in and guest buyers.

Related docs

• Shopify Functions API reference
• Shopify Functions input queries

As of August 31, 2026, changing the shipping address on an unfulfilled order through the order Update GraphQL mutation recalculates the order's taxes against the new destination. Previously, order Update saved the new address but left the original tax lines unchanged, so the order's totals no longer matched the destination it was shipping to.

Why it matters

The order's financial data is now corrected as part of the update, now totals stay accurate to the shipping destination. After updating a shipping address, query the order to read the updated tax Lines, total Tax Set, and totals, as you would for any other order edit. You don't need to make any changes to adopt this.

How it works

This change applies to all Admin GraphQL API versions. Taxes are recalculated only when the change is safe to apply, not on every address update. The address change always succeeds; only the tax recalculation is conditional.

Taxes aren't recalculated when:

• The order is partially fulfilled: On entirely unfulfilled orders, taxes are recalculated. On partially fulfilled orders, the address is saved but taxes are left unchanged, because some units have already shipped to the original destination, and recalculating the whole order against the new address would apply the new destination's tax to units that didn't ship there, producing totals that don't match what was actually fulfilled.
• The order can't be edited: Recalculation runs through order editing, so the same order-editing considerations apply. When an order isn't eligible for editing, the address is saved but taxes aren't recalculated.

Subscribers to the orders/edited webhook receive a notification when an address change results in a tax recalculation.

To learn more, see the order Update mutation.

Who's affected

The new Subscription Contract Calculation object on the GraphQL Admin API is now available in early access on the 2026-10 release candidate API version. It's the successor to the GraphQL Admin API's Subscription Draft object for creating, updating, and editing subscription contracts, replacing the multi-step draft workflow with a stateless calculate → poll → commit lifecycle that runs through Shopify's unified checkout engine.

Moving contract edits onto the unified checkout engine keeps calculations consistent with checkout, one calculate mutation replaces 12+ draft mutations, and new checkout capabilities work with contract edits without waiting on subscriptions-specific support. This affects any app that manages subscription contracts. If you build on subscriptions, you'll need to migrate to the new API to gain its new capabilities, but you can migrate incrementally, since both APIs will coexist.

This applies to any app that creates, updates, or edits subscription contracts using the Subscription Draft object. Apps that only read contracts or manage contract status (through subscription Contract Activate, subscription Contract Pause, and similar mutations) are unaffected. Status is still set through those dedicated mutations, not the calculation input.

The API is now available on the 2026-10 release candidate API version for early access and becomes stable on 2026-10.

What changed

Contract edits now run through the same C1 checkout engine that powers Checkout, Draft Orders, and subscription billing attempts, instead of the bespoke Subscription Draft engine that ran in parallel to checkout.

The previous workflow required a dozen-plus stateful mutations across the draft lifecycle to edit a single contract (create draft → add line → update line → remove line → add discount → apply code → update delivery → commit). The new API consolidates this into three calculate operations plus a shared commit:

• Calculate: submit the desired contract state in a single mutation: subscription Contract Create Calculate, subscription Contract Update Calculate, or subscription Billing Cycle Contract Edit Calculate.
• Poll: the calculate mutation returns a Subscription Contract Calculation Pending response. Poll the subscription Contract Calculation query, or subscribe to the subscription_contract_calculations/succeed and subscription_contract_calculations/fail webhooks, until you receive a Subscription Contract Calculation Success or Subscription Contract Calculation Failure.
• Commit: call subscription Contract Calculation Commit to persist the calculated snapshot.

Shopify calculates pricing, taxes, discounts, and Shopify Functions server-side and returns an immutable preview — including line, delivery, tax, duty, and discount totals — before you persist anything. Because the state is client-provided, any field you omit on update is preserved, so you only send what changed. For full details, see the migration guide.

Running through C1 also unlocks capabilities that were impossible with the drafts API: bundle products in contracts, cart transforms and delivery customization Functions, and pricing and tax that align with what the subscriber sees on recurring orders.

What to do

Action is required to adopt the new capabilities. The Subscription Draft object will be deprecated once the new API reaches general availability on 2026-10; it will remain available but won't support the new capabilities. Don't build production integrations until 2026-10 is stable.

We've written a full migration guide to support your move to the new API.

Related docs

• Migrate to the SubscriptionContractCalculation object
• Build subscription contracts

POS UI Extensions 2026-07 introduces the Printing API (shopify.printing), which enables extensions to discover hardware printers with getPrinters() and send documents directly to a connected receipt printer with print().

The Printing API supersedes shopify.print, which is now deprecated. No immediate action is required; plan to migrate when you adopt 2026-07.

What changed

• shopify.printing.getPrinters() returns the hardware printers available to the device. Each printer includes an id, name, and connected status.
• shopify.printing.print(src, options?) prints the document at src. If you omit options.printer, the system print dialog opens. If you pass a printer returned by getPrinters(), the document prints directly to that printer with no dialog.

The src must be either a relative path appended to your app’s application_url, or a full URL on the same origin. The document is fetched using the extension’s session token.

Receipt printers can render HTML and images directly. PDFs require the system print dialog: if you pass a printer when src points to a PDF, shopify.printing.print throws an error. For PDFs, always omit options.printer and rely on the system print dialog.

Previously, shopify.print could only open the system print dialog, which cannot target dedicated receipt printers. Earlier POS UI Extensions API versions are unchanged.

Note

Hardware printer discovery requires Shopify POS version 11.11.0 or later. On earlier versions, getPrinters() returns an empty array, even when a receipt printer is paired. This does not affect the system print dialog, which remains available.

Always handle the empty-array case by falling back to the system print dialog. This also covers merchants without a receipt printer:

const printers = await shopify.printing.getPrinters();
const receiptPrinter = printers.find((printer) => printer.connected);
if (receiptPrinter) {
  await shopify.printing.print('/print/receipt', { printer: receiptPrinter });
} else {
  await shopify.printing.print('/print/receipt');
}

The Printing API is available on all POS UI extension targets. To verify direct printing, test on a development store with POS 11.11.0 or later and a paired receipt printer. Call shopify.printing.print with a printer from getPrinters(); if the job prints without a dialog, direct printing is working.

Related docs

• Printing API reference
• Print API reference (deprecated)

Starting in API version 2026-10, the GraphQL Admin API returns an error when a query filters by a metafield that isn't set up for filtering, instead of silently returning incorrect results. This is a breaking change. It affects apps that filter resources by metafield on version 2026-10 or later, and you'll need to update affected queries before you upgrade.

What changed

In API version 2026-10 and later, the GraphQL Admin API checks metafield filters before it runs a query. If a query filters by a metafield that can't be used for filtering, the query returns an error explaining the problem instead of ignoring the invalid predicate and returning an incorrect result.

A metafield filter commonly fails when:

• The metafield doesn't have a definition.
• The metafield's definition isn't configured to allow filtering.
• The metafield's type doesn't support the filter or comparison you used.

Previously, invalid predicates in metafield filters were silently ignored, so a query with an invalid filter could return misleading results. Now the response tells you the filter is the problem, so you can correct it.

Who's affected

This change affects apps and integrations that filter by metafields in the GraphQL Admin API (for example, filtering products, orders, or customers by a metafield) on API version 2026-10 or later. Queries on version 2026-07 and earlier keep the previous behavior and aren't affected until you upgrade.

You're affected only when a query filters by a metafield that isn't valid for filtering. Queries that filter by metafields set up for filtering, using a supported comparison, behave exactly as before and return the same results.

Why this matters

Silently returning incorrect results made invalid metafield filters hard to catch: a mistyped or unsupported filter looked identical to a query that simply had different matches. Returning an error instead lets you find and fix these problems during development, rather than shipping a filter that quietly returns nothing in production.

Breaking changes and migrations

API version 2026-10 is scheduled for release on October 1, 2026. Once you make requests on 2026-10 or later, a query that filters by a metafield that isn't set up for filtering returns an error instead of an empty result.

To migrate:

• Find the queries in your app that filter by metafields in the GraphQL Admin API.
• For each one, confirm the metafield has a definition, the definition allows filtering, and the comparison you use is supported for that metafield's type.
• Update any filter that references a metafield that isn't set up for filtering.
• Test your queries against version 2026-10 and confirm they return results without an error.

If a metafield you rely on can't be filtered yet, keep those queries on version 2026-07 or earlier until you've updated your app, and set up the metafield definition for filtering before you upgrade.