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.

08-28-2026

More resilient refreshes for expiring offline access tokens

Expiring offline access token refreshes now retain the previously used refresh token until an app begins using its replacement. This rollout helps apps recover when a refresh response is lost or isn’t persisted. No migration is required, but apps should continue to store every refreshed token pair atomically. What changed Previously, after an app used a refresh token, it could retry that token for up to 60 minutes. If the app didn’t receive or save the newly returned access token and refresh token, the previously stored refresh token could no longer be used after that window. Now, an app can retry its previously stored refresh token until it starts using the replacement refresh token. This gives the app a recovery path after a lost response or storage failure. The recovery period is limited to 30 days from the original refresh token’s first use and doesn’t extend the token beyond its normal 90-day lifetime. When an app uses the replacement refresh token, the preceding refresh token is retired. Who's affected Apps that use expiring offline access tokens. It doesn’t require a new API version, configuration change, or opt-in. Apps that don’t use expiring offline access tokens aren’t affected. Why this matters A transient network interruption, worker failure, or database write failure can occur after Shopify processes a refresh request but before an app saves the returned token pair. This change lets affected apps recover without requiring a merchant to open the app again. What to do No migration is required if your app is already using expiring offline access tokens. Continue to: Serialize refresh operations for each shop. Persist each returned access-token and refresh-token pair atomically. Use the newest refresh token for future refreshes. Treat this behavior as a recovery path for lost responses, not as a reason to keep using an older refresh token after its replacement has been stored. Related docs Offline access tokens

08-27-2026

Password Protected Shop Dev flows on Shopify Theme CLI v3.83.x and older to be deprecated

Starting October 1, 2026, Theme commands on Shopify CLI for password protected storefronts will require version 3.84.0 or later. Versions 3.83.x and earlier will no longer be supported for theme development workflows on password protected storefronts. If you use Theme commands on Shopify CLI to develop or preview themes, upgrade to the latest version before October 1, 2026. Alternatively, you can remove the password protection on your storefront to continue using your preferred CLI version. What's changing Older Shopify CLI versions use a legacy storefront authentication. After October 1, 2026, this legacy authentication implementation will no longer be supported for theme development flows. This impacts only password protected stores. Developers using these versions for developing password protected storefronts may need to upgrade before they can continue using commands such as shopify theme dev. What you need to do Upgrade Shopify CLI to the latest version: npm install -g @shopify/cli@latest Then confirm your version: shopify version You should be on version 3.84.0 or later. We recommend using the latest available version, 4.7.0. Please follow the documentation if you are not using npm. Who's affected Developers who use Theme CLI commands on versions 3.83.x and earlier to develop password protected stores. The most likely affected workflows are: shopify theme dev shopify theme console shopify app dev if the app has theme app extensions Deprecation timeline October 1, 2026: Shopify will stop supporting storefront preview/session authentication from Shopify CLI versions 3.83.x and earlier. Related docs Shopify CLI for themes Theme development with Shopify CLI

08-26-2026

Four additional topics are now available for Events

Apps can now subscribe to events for Metaobject, MetafieldDefinition, MetaobjectDefinition, and InventoryTransfer. Apps can also subscribe to targeted metafield changes on InventoryTransfer. By subscribing to these topics, your app can react directly to changes in custom content, custom data definitions, and inventory transfer workflows. Apps can target the fields that matter in triggers, query the resource that changed, and avoid subscribing to broader updates just to diff payloads in their event handler. For example, the following subscription delivers when the value of the title field changes. The query uses the trigger's metaobjectId to fetch that Metaobject and field. [events] api_version = "unstable" [[events.subscription]] handle = "metaobject-event" topic = "Metaobject" actions = ["update"] triggers = [ "metaobject(type: 'books').field(key: 'title').value" ] uri = "/api/events" query = """ query MetaobjectTitleValue($metaobjectId: ID!, $fieldKey: String!) { metaobject(id: $metaobjectId) { id type handle field(key: $fieldKey) { key value } } } """ The complete payload body when the title field changes is as follows: { "topic": "Metaobject", "action": "update", "handle": "metaobject-title-value", "data": { "metaobject": { "id": "gid://shopify/Metaobject/123123", "type": "books", "handle": "metaobject-event", "field": { "key": "title", "value": "My Book Title" } } }, "fields_changed": [ "metaobject[id: 'gid://shopify/Metaobject/123123', type: 'books'].field[key: 'title'].value" ], "query_variables": { "metaobjectId": "gid://shopify/Metaobject/123123", "metaobjectType": "books", "fieldKey": "title" } } Events remain available in the unstable API version during developer preview. For topics that are not supported yet, continue using webhooks alongside Events. Learn more about: Events: https://shopify.dev/docs/apps/build/events Metaobject: https://shopify.dev/docs/api/events/latest/metaobject MetafieldDefinition: https://shopify.dev/docs/api/events/latest/metafield-definition MetaobjectDefinition: https://shopify.dev/docs/api/events/latest/metaobject-definition InventoryTransfer: https://shopify.dev/docs/api/events/latest/inventory-transfer

08-26-2026

Build Shopify apps in PHP and Python with new official packages

Shopify releases official PHP and Python app packages Shopify now publishes official, open-source packages for building apps in PHP and Python. shopify/shopify-app-php on Packagist and shopifyapp on PyPI have reached version 1.0. They provide framework-agnostic primitives for request verification, token exchange, and Admin GraphQL requests. If you build apps in PHP or Python, you can adopt them today. What changed Two new packages are generally available: composer require shopify/shopify-app-php pip install shopifyapp Both expose the same primitives, so you can compose the ones you need instead of adopting a full framework: Request verification for webhooks, App Home and App Bridge requests, app proxy requests, and Checkout, POS, Admin, Customer Account, and Flow extension requests Token exchange, including client credentials and refreshing exchanged access tokens An Admin GraphQL client with automatic retry handling They work with any stack, including Laravel, Symfony, Django, FastAPI, or plain PHP and Python. The previous shopify-api-php and shopify_python_api libraries are now deprecated. They continue to work, but will not receive new features or security fixes. shopify-api-php is marked as abandoned on Packagist, and shopify_python_api is marked as inactive on PyPI. Both point developers to the new packages. Who is affected This affects developers building Shopify apps in PHP or Python. It does not change anything for apps built with the Node.js or Ruby libraries, and React Router remains the recommended path for most new apps. Apps already using the older libraries continue to work with no immediate action required. Why this matters The packages are small and explicit. Each primitive maps to one step of the secure setup, making the flow visible in your code and easier for you or an AI tool to understand. They are also consistent across languages. Both packages implement the same contract and pass the same test suite, so improvements in one benefit the other. They are designed for incremental adoption, so you can migrate one route at a time instead of rewriting an entire app. What to do There is no app template for PHP or Python. Instead, scaffold your own project and compose the primitives you need. Each package’s README documents every primitive and can be provided as context to an AI coding tool when scaffolding your app. If you are starting a new PHP or Python app: Install the package for your language. Scaffold your project using your preferred framework or stack. Compose the primitives you need, for example by verifying an incoming request and then exchanging the token. Confirm that requests verify successfully and that token exchange returns an access token in a development store. Example PHP usage: $shopify = new Shopify\App\ShopifyApp($clientId, $clientSecret); $result = $shopify->verifyAppHomeReq($request); This example verifies an App Home request. On success, $result provides the verified $result->shop and $result->idToken, which you can exchange for an access token. It also includes a log and a response to return to the client. Use the matching verify... method for the surface you are handling, and use these values directly instead of parsing or re-verifying the request yourself. If you maintain an app using shopify-api-php or shopify_python_api, there is no forced migration or removal date. When you are ready, follow the upgrade notes in the new package’s README and migrate incrementally. Related docs Shopify libraries and templates Admin GraphQL API reference shopify-app-php on GitHub shopify-app-python on GitHub

08-26-2026

GitHub commits now name the last theme editor

When you edit a theme in the Shopify admin, the commit Shopify pushes to your connected branch now includes the editor's name in the body: Update from Shopify for theme Dawn Committed from shop: Snowdevil Theme last edited by: Bob Bobsen The name is plain text in the commit body. The commit author is still the shopify bot, so git blame and the commit avatar don't change. Edits saved within about 10 seconds of each other are batched into one commit, and the body names whoever saved last. If the theme has no recorded editor, the body lists only the shop name, as before. Learn more about the Shopify GitHub app in our developer documentation.

08-25-2026

Oxygen is now available on trial plan stores

You can now deploy Hydrogen storefronts to Oxygen from trial plan stores. Previously, Oxygen hosting required a paid plan. Note that trial plan stores don't include public environments, so deployment URLs always require a store login. Learn more about supported plans.

08-24-2026

Script tags are deprecated and will stop running on March 1, 2027

Starting October 1, 2026, the scriptTagCreate and scriptTagUpdate mutations will return an user error, and the ScriptTag REST Admin API resource will reject POST and PUT. The deprecation applies to all API versions, including older ones, so pinning won't defer it. On March 1, 2027, Shopify will stop injecting script tags into storefronts. Storefronts are the last place script tags still run, since they already stopped working on the Order status page. If your app uses a script tag to load JavaScript onto a store, then you need to replace it before then. What's changing A script tag loads JavaScript on a storefront without any changes to theme code. After March 1, 2027, Shopify won't inject those scripts, so script tags will stop loading JavaScript on storefronts. The scriptTags query and the scriptTagDelete mutation keep working, so you can audit and clean up your existing script tags. What you need to do Replace each script tag with an app embed block, which you ship in a theme app extension. App users activate app embed blocks in the theme editor. If a script only collects analytics or conversion data, then use a web pixel instead, which needs no action from the app user. Who's affected Apps that create script tags with a display_scope of online_store. Script tags with a display_scope of order_status are covered by an earlier deprecation. Refer to Order status script tags. Deprecation timeline October 1, 2026: scriptTagCreate and scriptTagUpdate will return an user error. Existing script tags will keep running. March 1, 2027: Shopify will stop injecting script tags into storefronts. Migration path App embed blocks replace script tags, and you ship them in a theme app extension. Refer to Storefront script tags to learn more. Related docs Storefront script tags Migrate to theme app extensions

08-19-2026

App intents on `admin.app.intent.link` now open as a full-page navigation

When Sidekick invokes an app intent declared on the admin.app.intent.link extension target, the Shopify admin now navigates the merchant to your extension's url as a full page, matching how Shopify's own admin intents behave. Previously, the same intent always opened in an overlay on top of the page the merchant was already on. This is live for all shops, isn't gated by API version, and doesn't require any changes to your extension's configuration, intent schema, or tools. Extensions that use the admin.app.intent.render target aren't affected. What changed App intents support different presentations. Until now, every app intent appeared as an intent modal, an overlay on top of the merchant's current page that kept them in the Sidekick flow. admin.app.intent.link intents now use a full-page navigation instead, which brings app intents in line with how admin intents, the intents that launch Shopify-native editors, are already presented. It also matches the documented behavior of the target, which navigates the merchant to a URL in your app for actions that work best on a page you already render. For implementation details, see Use extensions to surface app actions. There's one case where the overlay is still used: if the merchant has unsaved changes on their current page, the intent opens in a modal instead of navigating away, so their in-progress work isn't lost. Your extension doesn't need to handle these cases differently — the same route, payload, and tools are used in both presentations. The contract between Sidekick and your app is unchanged. Your route still reads the invocation payload from shopify.intents.request.value, a live signal that's null when your app isn't running inside an intent workflow and updates whenever an intent is invoked. You still register tool handlers with shopify.tools.register from the route the url opens, and you still resolve the intent with shopify.intents.response.ok(), shopify.intents.response.error(), or shopify.intents.response.closed(). Note: Extensions that target admin.app.intent.render currently render inline as an overlay, so a UI extension app action behaves the same as before. If you noticed this change before this post and reported it as a regression, the new behavior is expected. The type, target, and url on your extension continue to work as declared. Who's affected This applies to apps with an admin_link extension whose targeting includes admin.app.intent.link. It applies on every API version and every store, and there's no feature flag, scope, or setting to opt in or out. These aren't affected: Extensions targeting admin.app.intent.render. Admin intents your app invokes with intents.invoke() to launch Shopify-native editors. Those are a separate system and their presentation hasn't changed. Apps that don't declare app intents. If your app declares both targets, only the admin.app.intent.link intents change. Why this matters Merchants now land on the real page in your app, at the URL you declared, with your own layout and navigation instead of a constrained overlay. For the actions admin.app.intent.link is designed for, the merchant now works directly on the page your app already renders. What to do No action is required to keep your extension working. The declaration this change affects is the admin.app.intent.link target in your shopify.extension.toml: [[extensions.targeting]] target = "admin.app.intent.link" url = "/app/campaigns/{id}/edit" tools = "./tools.json" instructions = "./instructions.md" This example shows a typical admin.app.intent.link configuration: the target, the route the admin opens, and the files that define tools and instructions. You don't need to change this structure for the new behavior. If your app has no extension with that target, nothing changes for you. If it does, verify that the route behind url works as a standalone page: Confirm the route renders correctly at full width. Layout that assumed a narrow overlay may need adjusting. The route should also still render correctly in a modal, since that's the presentation merchants with unsaved changes will see. Confirm the route reads the invocation payload from shopify.intents.request.value. Because it's a live signal, you can also subscribe to it to react when the request changes. Confirm the route calls shopify.tools.register when it mounts, so Sidekick can invoke your tools while the merchant is on the page. Confirm you resolve the intent when the merchant finishes, fails, or cancels. Test in a development store with shopify app dev, then ask Sidekick to perform the action. You'll know the update worked when the admin navigates to your declared url with your schema's values substituted into the path rather than a literal {id}, your tools respond while the page is open, and Sidekick reports the result after you resolve the intent. To see the modal fallback, start editing a form in the admin and invoke the action before saving. Related docs Build Sidekick app extensions Intents API reference Tools API reference

08-18-2026

Hydrogen developer preview update: August 18, 2026

The Hydrogen developer preview adds new capabilities to the toolkit and extends the ways developers can build Shopify storefronts: Cart session attribution: Carts and Customer Account sessions stay in step, so signed-in shoppers reach checkout with their saved details instead of a guest flow. Cart attributes: Attach order-wide data like gift messages to the cart, and per-line data like engraving text to the lines it belongs to. Standard page view events: Hydrogen storefronts used to report only the first page load, leaving client-side navigations invisible to analytics and performance tooling. Every navigation now emits a page view, matching how liquid themes report events. Shop Pay button without shop-js: The button used to render blank until Shopify's hosted script loaded. Hydrogen now renders it directly, so it shows up styled and clickable right away, before any JavaScript runs. Local HTTPS for Customer Account development: Test login flows on a trusted local hostname, without a tunnel or hand-rolled certificates. Pluggable logging: Set how much Hydrogen logs and forward warnings and errors to your own observability tooling. To get started, visit the Hydrogen developer preview documentation. For a detailed breakdown of this release, read the full release notes.

08-10-2026

Shop Campaigns performance data now available via ShopifyQL

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 shopifyqlQuery 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 shopifyqlQuery 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").