apiPulse.app

Shopify

Storefront and admin API updates

Shopify API Changelog Monitoring

Shopify teams ship against a platform that changes constantly across storefront, admin, checkout, and app surfaces. This page is built for Shopify API Changelog Monitoring so you can review updates in one place and decide quickly whether a change affects your storefronts, apps, or merchant workflows.

A practical Shopify API Changelog Monitoring workflow makes it easier to spot breaking changes, new requirements, and deprecations early. That means less reactive debugging, better sprint planning, and a clearer path for testing storefront, admin, and app behavior before merchants notice issues.

The benefit of Shopify API Changelog Monitoring is simple: your team gets a repeatable way to watch changes, evaluate risk, and act before small upstream updates turn into customer-facing bugs. Storefront and admin API updates

Shopify API down?

Shopify API down? Soon we will add direct API status monitoring alongside Shopify API Changelog Monitoring. For now, go to the official API status page on the Shopify website. In the future, we plan to detect when Shopify APIs may be down even before the public status page is updated.

Recent changes

Showing the last 10 changes from this feed.

10-15-2026

Build with confidence: Shopify AI Toolkit's security check

Shopify AI Toolkit now includes shopify app security check, a security command that checks your app for common vulnerabilities before you ship. You can run it before you submit an app, and on every release, to find problems in your own code and get guidance to fix them. As AI accelerates how you build apps, attackers use the same tools to find and exploit security gaps faster and at lower cost. This tool helps you keep pace by scanning your app for the kinds of issues we see most often in Shopify apps. What's new shopify app security check is a new command in Shopify AI Toolkit and Shopify CLI that scans your app for security vulnerabilities. The command runs locally on your development machine and focuses on the most common vulnerability patterns in Shopify apps. It examines: Your app’s codebase Configuration across your app’s extension points The dependencies your app relies on Each finding helps you determine where a potential problem is, the possible impact, and how to fix it. You can learn more in the Shopify app security checks guide. Why we're making this change Merchants trust your apps with orders, customer data, and revenue. To protect that trust, your app needs to keep pace with evolving security threats and patterns. Partners who tested the tool reported finding issues they didn’t know about, including gaps in authentication and in how merchant data was isolated across stores. By running the command and iterating with a coding agent, they were able to improve their security posture without changing their existing stack or framework. Security remains a shared responsibility. This tool complements Shopify’s existing platform protections and your own reviews so you can catch more issues earlier in development. How it works With Shopify AI Toolkit installed, ask your coding agent: /shopify Check my app for common security vulnerabilities This directs your agent to run shopify app security check using Shopify CLI. Run it directly to see the provided prompts and context. And because your agent reads your code, the check isn’t tied to one framework. It supports both public and custom apps, whether you use React Router, Rails, Django, Laravel, or custom authentication, it examines how your app actually works and knows what gaps to look for. Each finding includes: The affected file and line The severity and why the issue matters A code example that shows one way to fix it Links to relevant documentation that explain the pattern and the fix Start with critical and high-severity findings. Work through them with your coding agent or fix them yourself, review the changes, and run the check again. Make it part of every release. A clean report isn’t a guarantee of security: use it alongside your existing tools and reviews. Help make the tool better Security is a shared responsibility. We made the tool open source so Shopify and app developers can improve it together. Share your feedback with us in the Forum, or contribute improvements directly through the open-source GitHub repository. Your feedback helps make future checks more useful for everyone. Securing the ecosystem is a priority and one we will continue to invest in, including existing measures you can find here. If you haven't adopted these, now's the time. Run the check on your app today, then fix what it finds to keep your app secured. Apps that keep up with security guidelines will be in the best position to protect merchants and their business. It’s essential that we prioritize this work together. Resources Shopify app security checks Secure your Shopify app

10-15-2026

Checkout footer visibility now applies to merchant-configurable content

The visibility fields on CheckoutBrandingFooterContent and CheckoutAndAccountsConfigurationBrandingFooterContent now control only merchant-configurable footer content. Checkout can display Shopify-provided transaction information in the footer regardless of this setting. Existing apps don’t need to change their GraphQL Admin API requests, but apps that preview or test checkout branding shouldn’t assume that HIDDEN produces an empty footer. What changed Checkout can now display Shopify-provided copy in the footer for eligible orders. This content is part of checkout and isn’t controlled by the footer content visibility setting or configurable through checkout branding. The visibility setting continues to control merchant-configurable footer content, including merchant policy links and copyright copy. Setting it to HIDDEN hides that merchant-configurable content without suppressing Shopify-provided footer content. The descriptions for the following GraphQL Admin API fields now clarify this boundary: CheckoutBrandingFooterContent.visibility CheckoutBrandingFooterContentInput.visibility CheckoutAndAccountsConfigurationBrandingFooterContent.visibility CheckoutAndAccountsConfigurationBrandingFooterContentInput.visibility No fields, input types, enum values, access scopes, or mutations have changed. Who's affected This change affects apps that customize checkout branding for Shopify Plus stores through either the legacy Checkout Branding API or the Checkout and Accounts Configuration API, especially if they manage footer visibility or render previews. All checkouts and Thank You pages now display the additional Shopify-provided footer copy. Apps that don’t manage checkout footer visibility are unaffected. The clarification applies to every GraphQL Admin API version where the corresponding branding type exists. It isn’t tied to a new API version. Why this matters This change clarifies the boundary between merchant-configurable branding and content that checkout provides. You can continue controlling merchant policy and copyright content while checkout presents relevant order context in the footer without changing the main checkout layout. Branding previews and automated tests can now treat Shopify-provided footer content separately from merchant-configurable content, so you can represent the rendered checkout footer more accurately. What to do No action is required to keep existing integrations working. Existing mutations and stored branding configurations continue to work without changes. If your app manages or previews checkout branding: Check whether it assumes that visibility: HIDDEN removes all footer content. Update previews and visual tests to allow Shopify-provided transaction information to remain visible when visibility hides only merchant-configurable content. Related docs CheckoutBrandingFooterContent reference CheckoutBrandingFooterContentInput reference CheckoutAndAccountsConfigurationBrandingFooterContent reference CheckoutAndAccountsConfigurationBrandingFooterContentInput reference

10-14-2026

Hydrogen 2026-10 is now available

The new Hydrogen is generally available today. Since the developer preview started in June, we've shipped seven releases based on feedback from developers using it. The big deal about the new Hydrogen is that it isn't a big deal: Hydrogen now works with any JavaScript framework. You can bring Shopify's commerce to your stack just by adding the library to your app, instead of needing to replatform. Hydrogen then handles commerce for you: the cart, variant selection, prices in the buyer's currency, analytics that respect consent, Shop Pay, and customer login. React Router and Next.js have starters ready to deploy, and you can host it anywhere, including Oxygen, which is still free. The package also includes skills that teach coding agents how to use it. To try it in an existing project, run npx @shopify/hydrogen@latest setup and ask your agent to "Set up my store with Shopify." What Hydrogen gives you Every Shopify storefront needs the same commerce pieces, and they're harder to get right than they look. The cart has to stay correct when a shopper taps "Add to cart" twice. Prices have to match the buyer's country and currency. Analytics have to respect consent and still reach Shopify, or your reports go quiet. Hydrogen handles those for you: the cart, product variants, collection filters, predictive search, Markets, analytics, Shop Pay, and customer accounts. Your framework keeps routing, data loading, and rendering, and the design is all yours. The glue code fits in a few lines. For instance, a dynamically updating cart count in React looks like this: import { createCartComponents } from "@shopify/hydrogen/react"; const { CartProvider, useCart } = createCartComponents(); function CartCount() { const count = useCart((cart) => cart.data.totalQuantity); return {count}; } Vue has the same thing as a composable, and other frameworks subscribe to the cart directly. Built for coding agents Hydrogen comes with 20 skills that teach coding agents how to use it, covering each part of a storefront. We wrote them by building storefronts with agents and fixing the skill every time an agent got something wrong. Ask your agent to "Set up my store with Shopify," and it builds the home, collection, search, product, cart, and account pages, adds analytics, and smoke-tests the result. The skills live in your project and match the version of Hydrogen you installed, so your agent follows instructions for the code you actually have. After you upgrade Hydrogen versions, you can update the skills with npx @shopify/hydrogen skills sync. Hydrogen storefronts also work with shopping agents. In browsers that support WebMCP, an agent can search your catalog and update the cart, and after the buyer confirms, Shopify Checkout can submit the order with complete_checkout. You don't have to build anything for it. Hydrogen uses the same standard storefront actions as Liquid themes, so compatible apps, storefront UI, and agents can share the same cart contract. An app or agent adds to the cart by calling the same action your own UI uses: await window.Shopify.actions.updateCart({ lines: [{ merchandiseId: "gid://shopify/ProductVariant/123", quantity: 1 }], }); If you've used Hydrogen before Hydrogen used to be a framework built on React Router. To use its cart or analytics, you built your whole storefront on it. Now it's a library, so you can add it to the framework you already use and host it wherever you want. Oxygen is still free. Existing Hydrogen storefronts keep working as they do now, and there's nothing you need to do today. When you're ready to move, the migration skill walks your agent through it. You keep your pages and routes and swap where the commerce code comes from. Get started There are a few ways to get started: Run npx @shopify/hydrogen@latest setup in your own project. Deploy the React Router template to Oxygen from your Shopify admin. If you use Next.js, clone Vercel Shop, a storefront built on Hydrogen and maintained by Vercel. If something's missing or broken, tell us in the Shopify developer community. The code is on GitHub, and the docs are on shopify.dev.

10-13-2026

Add shopping and Shop Pay checkout to any agent with Shop MCP

Shop MCP lets your agent or app search Shopify Catalog, build carts, and complete Shop Pay checkout through a single MCP connection. It works with over 1 billion products in Shopify Catalog and doesn't require an API key for search. Nothing changes for existing Catalog API integrations, and no action is required. What changed Shop MCP is live at https://mcp.shop.com, with a skill description at https://mcp.shop.com/skill.md that MCP-compatible agents can read. One connection gives your agent tools, grouped into a few main flows: Search and product details: search_catalog, lookup_catalog, and get_product read from Shopify Catalog. Sign-in with Shop: the shopper signs in once, and search tools use their saved preferences. Carts and checkout on Shopify stores: your agent builds a cart and creates a checkout at the store that sells the product. Carts and checkout work without sign-in. With a signed-in shopper, checkout can use their saved addresses and Shop Pay, and your agent completes the purchase with complete_checkout after the shopper confirms the total and payment method. Orders: for a signed-in shopper, your agent finds orders and tracking with search_orders. The shop CLI calls the same server from your terminal so you can try a search before you write any code: npm install -g @shopify/shop shop search "ceramic coffee dripper" Each result shows the store, the price, and whether it's in stock. Replace the query with a product your agent sells to see the shape of the data your agent receives. Orders placed through your agent appear in the merchant's Shopify admin like any other order. There are no webhooks at launch, so you need to poll get_checkout for checkout status. Who's affected Developers who build or configure MCP-compatible agents or tools can use Shop MCP. If you use the existing Catalog API directly, your current integrations keep working without changes. Why this matters Before Shop MCP, your agent could find a product in Catalog but had to send the shopper to the store's website to pay, which often caused drop-off. Now a signed-in shopper can pay with the Shop Pay details they've already saved without leaving your agent. What to do No action is required for existing integrations. To start using Shop MCP: Install the shop CLI and run shop search with a query to check results from your terminal. Point your coding agent at https://mcp.shop.com/skill.md, or add https://mcp.shop.com as an MCP server in your agent's config. To pay with Shop Pay, have the shopper sign in with Shop. MCP clients such as Claude and ChatGPT run sign-in for you, and your own code can use the device flow. Test a purchase end to end. It worked if the checkout returns status: completed with an order. Search works without credentials. Create an API key in the Shopify Dev Dashboard. Related docs Shop MCP overview Global Catalog MCP

10-12-2026

Cart updates that result in no changes to the cart no longer trigger carts/update webhooks

Cart operations that leave the cart unchanged, for example, resubmitting the same values a cart already has, no longer trigger a carts/update webhook. Shopify sends a webhook every time a cart's contents or properties change. Previously, every cart operation produced a carts/update webhook. This change removes the duplicate notifications, and apps receive one carts/update for each change to a cart instead of one per request. Learn more Cart webhooks Ajax Cart API

10-12-2026

Detect when a POS extension screen finishes navigating

What changed The POS Navigation API adds the navigatesuccess event. It fires after the destination screen finishes its native transition, and its callback receives a standard Event. currententrychange can fire before the screen finishes appearing, and the navigate() promise doesn’t wait for the transition. When navigating back, register the listener on the screen that will reappear; the screen being left is removed. Who’s affected The event is available to POS UI extensions that target API version 2026-10 and run on POS builds that support it. Older POS builds won’t emit navigatesuccess. What to do No migration is required. To act after a screen finishes appearing, listen for navigatesuccess. Don’t use the navigate() promise as a signal that the native transition has finished.

10-12-2026

Identify the published version running in a POS extension

What changed shopify.extension.version returns the version of the extension that is running. It’s the same name shown on the Versions page in the Dev Dashboard and chosen when running shopify app deploy. The value is an opaque name, not a version number, so compare it for equality rather than sorting it. It’s undefined when the extension runs from a local development server. Who’s affected This field is available to POS UI extensions that target API version 2026-10. Extensions targeting earlier API versions are unchanged. Why this matters POS can cache extension bundles and run them offline. The field helps developers identify which published build a merchant’s device is running. What to do No action is required for existing extensions. To use the field, target API version 2026-10. Account for undefined when testing from a local development server. Related docs POS UI Extensions API, version 2026-10

10-09-2026

Global Catalog REST API stops serving traffic on November 2, 2026

The Global Catalog REST API, which was deprecated in April 2026, stops serving traffic on November 2, 2026. If your app still calls it, you need to migrate to Global Catalog MCP, which implements the Universal Commerce Protocol (UCP), before that date.

10-09-2026

Catalog API now returns compare-at prices as `list_price`

The Catalog API now returns a merchant’s compare-at price as list_price on each product variant. Your app or agent can use list_price to tell when a product is marked down and by how much. The price field doesn’t change. No action is required. list_price is an optional field defined in the UCP catalog specification, version 2026-08-25. It uses the same Price object as price, with amount in minor units and a currency. Products also return list_price_range, which includes the lowest and highest list_price across their variants. A variant includes list_price when all of the following are true: The merchant shares compare-at prices through Catalog Mapping in the Shopify admin. Shopify turns this on by default for most stores and turns it off for stores that use compare-at for MSRP or another reference price. The compare-at price is higher than price for the buyer’s context. The merchant shows compare-at prices in the buyer’s region. Stores that hide them from EEA buyers don’t return list_price to those buyers. When list_price is missing, the variant has no compare-at price to show for that buyer and configuration. How you present that in your UI or in an agent’s response is up to you. Learn how list_price appears in Global Catalog responses.

10-08-2026

New `owner_type` field for metafield declarations in Checkout and Customer Account UI extensions, required in 2027-01

Starting with API version 2026-10, Checkout and Customer Account UI extensions can specify an owner_type for each metafield declaration in shopify.extension.toml. Starting with API version 2027-01, owner_type is required for every metafield declaration, and deployments without it will be blocked. What changed Metafield declarations in [[extensions.metafields]] and [[extensions.targeting.metafields]] accept a new owner_type property. owner_type names the resource that owns the metafield, such as PRODUCT or CUSTOMER. Shopify uses owner_type to fetch only the metafields from the resource types your extension needs, which improves extension performance. On API version 2027-01 and later, every metafield declaration must include owner_type. Who's affected Checkout and Customer Account UI extensions that declare metafields in shopify.extension.toml and use API version 2027-01 or later are affected. Extensions that don't declare metafields in shopify.extension.toml are unaffected. What to do On API version 2027-01 or later, deployments will be blocked if any metafield declaration is missing an owner_type. Add owner_type to each metafield declaration before you upgrade. You can add it now on 2026-10. To migrate: Open your extension's shopify.extension.toml file and add the appropriate owner_type value for each metafield declaration. If your extension needs the same namespace and key from multiple resource types, create a separate declaration for each owner_type. Redeploy the extension and confirm that the deployment completes without validation errors related to metafield declarations. Related docs Configure metafields for Checkout UI extensions Configure metafields for Customer Account UI extensions