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.

04-01-2026

Deprecation of checkout metafields in checkout and customer account UI extensions

As of API version 2026-04, we removed the ability to read and write checkout metafields in checkout and customer account UI extensions. Checkout metafields are now replaced by cart metafields in checkout UI extensions and order metafields in customer account UI extensions. Action required If you are using checkout metafields in older API versions, upgrade to 2026-04 and follow our guides: Migrate to cart metafields in checkout UI extensions Migrate to order metafields in customer account UI extensions Notably, order metafield definitions now support a new capability that copies values from cart metafields to order metafields at order creation. Learn more

Source

04-01-2026

Add Prerequisites to Product Discount Functions

Discount functions now support prerequisites for product discount candidates, allowing you to define the "Buy X" portion of a Buy X, Get Y (BXGY) discount. In a BXGY discount, customers must purchase a specified quantity of one product (Buy X) to receive a discount on another product (Get Y). What's New: A prerequisites field has been added to product discount candidates. Each prerequisite is defined as a cartLinePrerequisite, which includes: id: The identifier for the cart line used as the prerequisite. quantity: The number of items from that cart line required to qualify for the discount. For more detailed information, please visit the Discount Functions documentation.

Source

04-01-2026

Add Tags to Discounts

Starting in API version 2026-04, discounts support tags allowing you to efficiently label, group, and organize your discounts. What's new: The tags field has been added to all discount types Tags can be added, updated, and removed via the Admin API For more information, visit the Admin API documentation

Source

04-01-2026

Adding access field to StandardMetaobjectDefinitionTemplate

We are introducing a new access field to the StandardMetaobjectDefinitionTemplate. This field will display the template's access rules, helping you determine if a specific template is configured for access via the Storefront API. By understanding these access rules, developers can plan their API interactions more effectively, ensuring seamless integration with the Storefront. The StandardMetaobjectDefinitionTemplate is a component that defines the structure and behavior of metaobjects within Shopify. With the new access field, you can proactively verify access configurations, optimizing your development workflow and enhancing the user experience.

Source

04-01-2026

`delegateAccessTokenCreate` mutation now returns `expiresIn`

We have introduced an expiresIn field to the DelegateAccessToken type, which is returned by the delegateAccessTokenCreate mutation. This addition allows app developers using delegate tokens to know precisely when their tokens will expire. The expiresIn field provides the number of seconds remaining until the token expires, aligning with the data available through the REST Admin API's delegate endpoint. This feature is particularly beneficial when the expiresIn input is not specified, causing the delegate token to inherit the parent token's Time to Live (TTL). Previously, developers had no means to ascertain the expiration time of such tokens. This update is available in GraphQL Admin API version 2026-04 and later.

Source

04-01-2026

Line item component information now available for draft orders on the Customer Account API

As of Customer Account API version 2026-04, the DraftOrderLineItem object includes a new components field. This field returns the individual component line items associated with a parent line item. Additionally, a new optional argument, flattenComponents, has been introduced to the DraftOrder.lineItems connection. For API versions 2026-04 and later, flattenComponents defaults to false, meaning only top-level line items are returned as nodes, with their components accessible via the DraftOrderLineItem.components field. If set to true, both parent and component line items are returned as top-level nodes, aligning with the behavior of earlier API versions. For versions prior to 2026-04, flattenComponents defaults to true to ensure backward compatibility. Example query { draftOrder(id: "gid://shopify/DraftOrder/1") { lineItems(first: 10) { nodes { name quantity components { name quantity } } } } }

Source

04-01-2026

App-owned metaobjects can be used without access scopes

App-owned metaobjects, identified by types such as $app:example, including those created using declarative metaobject definitions, can now be utilized by their owning app without requiring any access scopes. This change simplifies the process for developers by eliminating the need to request additional access scopes, thereby reducing potential merchant friction. If you are considering using declarative metaobjects in your app, you can now proceed without worrying about additional access scope requests. Ensure you are using Admin API version 2026-04 or later to read or write app-owned metaobjects without the need for additional access scopes. Working with merchant-owned metaobject types still requires specific access scopes, such as read_metaobjects or write_metaobject_definitions, to be granted.

Source

04-01-2026

Removing outdated Polaris reference docs

Polaris reference docs now follow the same versioning policy as Shopify's GraphQL APIs: Each stable version is supported for a minimum of 12 months. Older versions continue to work, they just won’t have dedicated docs on Shopify.dev. Shopify CLI already prevents deploys targeting API versions older than 12 months, so we recommend keeping your extensions on a supported version. Starting with the 2026-04 release, we'll only publish docs for the last four stable versions of these reference docs: Admin UI extensions Checkout UI extensions Customer account UI extensions POS UI extensions

Source

04-01-2026

Cart and checkout validation adds billing address and PO number error targets

As of API version 2026-04, you can validate billing addresses and purchase order (PO) numbers in Cart and Checkout Validation Functions. We've added billing address and PO Number to the function input graph and introduced new checkout field targets. This allows you to enforce compliance rules such as blocking prohibited billing countries and requiring PO numbers for B2B orders without relying upon client-side UI extensions. What's changed Input graph fields: billingAddress and poNumber are available on all Shopify Function input graphs. They return null outside of Cart and Checkout Validation. Supported checkout field targets for error messages in Cart and Checkout Validation: $.cart.billingAddress.{field} (all standard address subfields) $.cart.poNumber Impact No breaking changes. Your existing functions continue to run. You can optionally add validations for these targets. Checkout surfaces field-level errors for billing address and PO number when your function returns validations for these targets. To learn more, see the developer documentation.

Source

04-01-2026

Multi-channel support for sales channel apps

Sales channel apps can now create and manage multiple channel connections from a single app. A single app can now establish more than one channel on a shop, with a separate specification and/or external account for each connection. Why this matters If you build a sales channel app that needs separate connections for different accounts or to sell in different markets or have different surfaces, you no longer need to split that model across multiple apps. You can keep those connections inside one app and manage them as distinct channels. What's new A single sales channel app can establish multiple channels on the same shop. Sales channels can now uses the Channel Config extension plus one specification file per target channel. Each channel can point to a different specification and external account. What partners should do For new sales channel apps All new sales channels should add a Channel Config extension. Define one specification file per target channel. Use channelCreate with a specificationHandle, accountId, and accountName to create each channel connection. For existing sales channel apps Migrate legacy sales channel app to use channel connections using this guide Review any downstream code that assumes one channel per app. If your app reads or mutates channel-specific state, pass a channel ID instead of relying on app-level defaults. New APIs in this release channel channelCreate channelByHandle channelUpdate channelDelete channelFullSync APIs impacted by this release Deprecated: These single-channel APIs are now deprecated. They still function today but will be removed in a future API version: | Deprecated API | Use instead | |

Source