# Recent changes to Shopify’s platform --- ## New Catalog APIs As of April 2025, the Catalog APIs have been updated to support changes in how markets are managed. For more details, see the [New Markets APIs](https://shopify.dev/changelog/new-markets-apis). With these updates, multiple markets can now be assigned to a single catalog. Consequently, the [`MarketCatalog.markets`](https://shopify.dev/docs/api/admin-graphql/2025-04/objects/MarketCatalog#connection-markets) connection will no longer guarantee the return of a single entry. Additionally, the `Market` object now supports new conditions. Previously, only `RegionConditions` were available for a market; now, `CompanyLocationConditions` are also supported. To maintain the existing behavior and access only `Regions`, you must update the `markets` connection by using the `type: REGION` argument. *Published: January 29, 2025* Tags: API, Breaking API Change Link: https://shopify.dev/changelog/new-catalog-apis --- ## shop.metaobjects is now just metaobjects in liquid We've simplified access to metaobjects in Liquid. You can now access metaobjects using the streamlined syntax `metaobjects.type.handle`, aligning with conventions used for other resource types. This new approach is more standardized and is now the preferred method. The previous access syntax, `shop.metaobjects.type.handle`, remains functional and backward compatible but is officially deprecated. [Learn more](https://shopify.dev/docs/api/liquid/objects/metaobject) about metaobjects in liquid *Published: January 28, 2025* Tags: API, Update Link: https://shopify.dev/changelog/shopmetaobjects-is-now-just-metaobjects-in-liquid --- ## Apps will be reviewed for necessary scopes Starting February 1, 2025, all apps submitted to the Shopify App Store will be checked for scopes that require Shopify permission for approved use cases. Apps that have unnecessary scopes, or are using scopes for non-approved use cases will have these scopes removed. To learn more about these scopes, please visit the `API access` page in your Partner Dashboard. *Published: January 24, 2025* Tags: Shopify App Store, New Link: https://shopify.dev/changelog/apps-will-be-reviewed-for-necessary-scopes --- ## InventoryItem Queryable and Updatable with Products Scopes The scopes for the [InventoryItemInput](https://shopify.dev/docs/api/admin-graphql/2025-01/input-objects/InventoryItemInput) input object and the [InventoryItem](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/InventoryItem) object have been relaxed. These objects can now be updated and queried using the `write_products` and `read_products` scopes, respectively. Specifically, the following changes have been made: - The `InventoryItemInput` can now be set within `product*` mutations using only the `write_products` scope. - The `InventoryItem` can be queried with either the `read_products` or `read_inventory` scope. However, the following restrictions still apply: - The `inventoryLevel` cannot be queried from the `InventoryItem` object without the `read_inventory` scope. - The `location` cannot be queried without the `read_locations` scope. These changes are applicable across all API versions. *Published: January 22, 2025* Tags: API, New Link: https://shopify.dev/changelog/inventoryitem-queryable-and-updatable-with-products-scopes --- ## Support added for $app in product queries by metafield We now support querying products by app-owned metafields with a saved namespace using the `$app` syntax. To include an app-owned metafield in your query, you can use the syntax `metafields.$app.key:\"value\"` or `metafields.$app\\:optional-additional-text.key:\"value\"`. [As documented](https://shopify.dev/docs/api/usage/search-syntax#special-characters), special characters need to be escaped from queries. For this reason, you need a `\\` when specifying `:`. For example, suppose you have an app-owned metafield with the optional-additional-text `swatch-app` and key `color` with a value of `green`. To query for products with this metafield, you would use the following search syntax: `"metafields.$app\\:swatch-app.color:\"green\""` Learn more about [querying products by metafield value](https://shopify.dev/docs/apps/build/custom-data/metafields/query-by-metafield-value) and [creating metafields with reserved namespaces](https://shopify.dev/docs/apps/build/custom-data/ownership#create-metafield-definitions-with-reserved-namespaces). *Published: January 20, 2025* Tags: API, Update Link: https://shopify.dev/changelog/support-added-for-app-namespaces-in-product-queries-by-metafield --- ## Continuous cart authentication We’ve recently rolled out a change that enables continuous authentication when a customerAccessToken is appended to the cart in the buyerIdentity object. The obtained checkoutUrl allows authenticated customers to navigate to a logged-in checkout experience. Note that for security reasons, the checkoutUrl should be requested when the customer is ready to navigate to checkout, which can be re-requested if needed. To log in customers automatically at checkout, please [append the customerAccessToken](https://shopify.dev/docs/storefronts/headless/building-with-the-storefront-api/cart/manage#step-6-authenticate-customer-for-logged-in-checkouts) into the Buyer Identity object of the Storefront API Cart and [include the buyer IP address](https://shopify.dev/docs/api/usage/authentication#making-server-side-requests) when making server side requests. For developers building mobile apps with the Checkout Sheet Kit, see this [detailed guide](https://shopify.dev/docs/storefronts/headless/mobile-apps/checkout-sheet-kit/authenticate-checkouts) to create authenticated checkout experiences for buyers within mobile apps. Previously, opening an authenticated checkout was only possible using multipass limited to Shopify Plus plans and legacy customer accounts. Now, authenticated checkouts are possible for merchants on all plans and customer account versions. *Published: January 16, 2025* Tags: API, Update Link: https://shopify.dev/changelog/continuous-cart-authentication --- ## New Buyer Consent Requirement As of Tuesday, February 18, 2025, all published apps must display costs and obtain explicit buyer consent before adding any optional paid items to Storefront, Cart, or Checkout.  These requirements are already being enforced on unpublished apps. We've updated our [Checkout UI extension app requirements](https://shopify.dev/docs/apps/launch/app-requirements-checklist?utm_source=mozart&utm_medium=email&utm_campaign=app_requirement&utm_content=optional_paid_items#18-checkout-ui-extension-apps) and [prohibited app types](https://shopify.dev/docs/apps/launch/app-requirements-checklist?utm_source=mozart&utm_medium=email&utm_campaign=app_requirement&utm_content=optional_paid_items#1-prohibited-and-restricted-app-configurations) to make buying experiences more trustworthy. These requirements apply to both packaged Checkout UI extensions and any downloadable code provided by the app or app partner across Storefront, Cart, and Checkout. *Published: January 16, 2025* Tags: Shopify App Store, New Link: https://shopify.dev/changelog/new-buyer-consent-requirement --- ## Line item weight input for `orderCreate` mutation We have enhanced the `orderCreate` mutation by adding an optional field, `OrderCreateLineItemInput.weight`, which allows you to specify the weight of each line item using the `WeightInput` object. For line items linked to a product variant: - Specifying a weight will override the variant's default weight. - If no weight is specified, the variant's weight will be used by default. For line items not linked to a product variant, such as custom items: - Specifying a weight will apply that weight to the line item. - If no weight is specified, the line item's weight will default to 0. This is an improved version of the `line_items.grams` field that exists in the [REST API](https://shopify.dev/docs/api/admin-rest/unstable/resources/order#post-orders). *Published: January 15, 2025* Tags: API, New Link: https://shopify.dev/changelog/line-item-weight-input-for-ordercreate-mutation --- ## Expose the id field in ProductFullSyncPayload object As of version 2025-04, the return field id in product full sync payload in Admin API will be available. *Published: January 15, 2025* Tags: API, Update Link: https://shopify.dev/changelog/expose-the-id-field-in-productfullsyncpayload-object --- ## New `inventoryItem` field on ProductSetVariantInput We are expanding capabilities of the GraphQL Admin API [**productSet**](https://shopify.dev/docs/api/admin-graphql/latest/mutations/productSet) mutation by adding `inventoryItem` field to the [**ProductVariantSetInput**](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/ProductVariantSetInput) type. This enables `productSet` to modify `ProductVariant` fields related to its `inventoryItem`, such as unit cost and tracked status . This change is applied to all API versions, starting with `2024-10`. For more detailed information and examples, visit our [productSet documentation](https://shopify.dev/docs/api/admin-graphql/latest/mutations/productSet) on Shopify.dev. *Published: January 15, 2025* Tags: API, New Link: https://shopify.dev/changelog/new-inventoryitem-field-on-productsetvariantinput --- ## Performance, integration and category-specific requirements come into practice To ensure that the Built for Shopify status represents the highest quality of app apps will need to meet the following performance, integration and category-specific requirements. These requirements are designed to ensure that each app that earns the Built for Shopify status excels in meeting the unique needs of the merchants it serves. Built for Shopify annual review will be on January 2, 2025. ### **Performance requirements** Date enforced: January 2, 2025 * [Make the admin performance meet 75th percentile Web Vitals targets](https://shopify.dev/docs/apps/launch/built-for-shopify/requirements#make-the-admin-performance-meet-the-th-percentile-web-vitals-target) * [Cumulative Layout Shift (CLS)](/docs/apps/build/performance/admin-installation-oauth#cumulative-layout-shift): will be re-introduced and needs to be 0.1 or less. * [Interaction to Next Paint (INP)](/docs/apps/build/performance/admin-installation-oauth#largest-contentful-paint): 200 milliseconds or less. *This requirement replaces the previous [First Input Delay (FID)](/docs/apps/build/performance/admin-installation-oauth#first-input-delay) requirement.* * [Minimize the impact on checkout speed](https://shopify.dev/docs/apps/launch/built-for-shopify/requirements#minimize-the-impact-on-checkout-speed) * Your app must make a minimum of 1,000 requests over the last 28 days. * Your requests must have a p95 value of 500ms or less, with a 0.1% failure rate. *These requirements will replace the following ones: Your app must make a minimum of 1,000 requests over three weeks. Your app must have a p99 value of 1000ms or less, with 0% failure rate.* ### **Integration requirements** Date enforced: January 2, 2025 * [Enable seamless sign up based on Shopify credentials](https://shopify.dev/docs/apps/launch/built-for-shopify/requirements#enable-seamless-sign-up-based-on-shopify-credentials) Apps should make sign up seamless for merchants, without requiring an additional login or sign-up prompt. Users should be able to begin using the app immediately after installing it without having to complete another sign up. [Exceptions](/docs/apps/build/integrating-with-shopify#exceptions) apply on apps that can’t be easily accessed by merchants in a self-service manner and require a more complex sign-up, often involving a business-to-business contract. In these cases, the first step to the in-admin onboarding of these apps must always be a workflow that enables a merchant to link the current store with their existing credentials.

If your app offers both self-service and business-to-business sign up, then the app's onboarding must include an option to sign up for the service using the merchant's existing Shopify credentials. * [Include simplified monitoring or reporting](https://shopify.dev/docs/apps/launch/built-for-shopify/requirements#include-simplified-monitoring-or-reporting) Expose key metrics that are helpful for merchants on the app’s home page. If your app includes monitoring or complex reports that can only exist on an external website or app surface, then you must include a simplified version of the monitoring or reporting in the Shopify admin. * [Keep third-party connection settings within Shopify](https://shopify.dev/docs/apps/launch/built-for-shopify/requirements#keep-third-party-connection-settings-within-shopify) Any settings or configurations that control the connection between Shopify and a third-party system must be available inside the Shopify embedded app interface. ### **Category specific requirements** We understand not all apps are the same. Apps are built to address a wide variety of merchant workflows and serve many diverse functions. Moving forward some categories of apps must adhere to additional requirements. These requirements specify specific APIs, integrations, and design guidelines that reflect what a great app in these categories looks like. **Product bundles apps** Date enforced: January 2, 2025 * [Use bundles primitives](https://shopify.dev/docs/apps/launch/built-for-shopify/requirements#use-bundles-primitives) Your app must either use the GraphQL Admin API to create [static bundles](https://shopify.dev/docs/apps/build/product-merchandising/bundles/add-fixed-bundle) or use a cartTransform function to create [customized bundles](https://shopify.dev/docs/apps/build/product-merchandising/bundles/add-customized-bundle). However, if your app supports a bundles use case that is not yet supported through these APIs *Published: January 11, 2025* Tags: Built for Shopify, Update Link: https://shopify.dev/changelog/performance-integration-and-category-specific-requirements-come-into-practice --- ## New card brands for OrderTransactions.paymentMethods The [`OrderTransactions.paymentMethods`](https://shopify.dev/docs/api/admin-graphql/unstable/enums/PaymentMethods) enumerated type now includes two new values: `CARTES_BANCAIRES` and `BANCONTACT`. Starting with API version `2025-04`, order transactions paid using these methods will reflect the new values in GraphQL API responses. *Published: January 10, 2025* Tags: API, Update Link: https://shopify.dev/changelog/new-card-brands-for-ordertransactionspaymentmethods --- ## Shopify Functions template and Shopify CLI changes to support Rust 1.84 In anticipation of the [removal of the wasm32-wasi build target in Rust 1.84](https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html), Shopify has updated its Shopify Functions templates for Rust. The `cargo-wasi` utility has been removed because it is incompatible with Rust 1.84 and later versions. Additionally, starting with Shopify CLI 3.73, all function builds now include an optimization pass by default. Previously, this optimization was handled by `cargo-wasi`. Before you update to Rust 1.84, we recommend reviewing and following the [steps outlined here](https://shopify.dev/docs/apps/build/functions/programming-languages/rust-for-functions#updating-to-rust-1-84-and-higher). These changes are compatible with Rust 1.78 and above. *Published: January 08, 2025* Tags: Tools, Update Link: https://shopify.dev/changelog/shopify-functions-template-and-shopify-cli-changes-to-support-rust-184 --- ## New validations on function input query variables metafields As of 2025-01, input query variables metafields will now be subject to additional validation across all Function APIs. Previously, if these metafields didn't contain properly formatted data, we treated them as empty. This could lead to situations where it was difficult to determine why a function wasn't receiving the expected input data. Now, an invalid metafield will result in an `InvalidVariableValueError` when attempting to run the function. For more information, refer to the [list of errors](https://shopify.dev/docs/apps/build/functions/monitoring-and-errors#list-of-errors). *Published: January 06, 2025* Tags: API, Update Link: https://shopify.dev/changelog/new-validations-on-function-input-query-variables-metafields --- ## Add tax validation with localizedFields in Checkout UI Extensions & Functions **As of Jan 6, 2025**, you can use the new localizedFields in the Checkout UI Extension API and Function API to implement custom validation for tax fields in checkout. The localizationExtensions field in the Admin GraphQL API has now been renamed to localizedFields too. Additionally, you can now target tax fields in checkout for error messages. Available currently in the unstable API version and will be released to the stable 2025-01 API version. Learn more on how to implement [localizedFields](https://shopify.dev/docs/apps/build/markets/add-locally-required-order-data#validate-a-country-field). *Published: January 06, 2025* Tags: API, Update Link: https://shopify.dev/changelog/add-tax-validation-with-localizedfields-in-checkout-ui-extensions-functions --- ## POS UI Extensions 2025-01 Update As of January 20, we added the following updates to POS UI Extensions: ### Breaking Changes - Removed the deprecated ActionItem component. Use a [Button](/docs/api/pos-ui-extensions/components/button) instead. - Removed the deprecated SmartGridApi. Use the [ActionApi](/docs/api/pos-ui-extensions/apis/action-api) instead. - Removed the deprecated DiscountType. Use [CartDiscountType](/docs/api/pos-ui-extensions/apis/cart-api#cartapi-propertydetail-applycartdiscount) and [LineItemDiscountType](/docs/api/pos-ui-extensions/apis/cart-api#cartapi-propertydetail-setlineitemdiscount) instead. - Removed the deprecated `badge` prop from the [List](/docs/api/pos-ui-extensions/components/list) component. Use `badges` instead. - Removed the deprecated `TextFieldProps` type from the [TextField](/docs/api/pos-ui-extensions/components/textfield) component. - Deprecated `'vertical'` and `'horizontal'` as values for the `direction` field in the [Stack](/docs/api/pos-ui-extensions/components/Stack) component. - Deprecated the `flexChildren'` field in the [Stack](/docs/api/pos-ui-extensions/components/Stack) component. - Deprecated the `flex'` field in the [Stack](/docs/api/pos-ui-extensions/components/Stack) component. - Deprecated the `flexWrap'` field in the [Stack](/docs/api/pos-ui-extensions/components/Stack) component. - Deprecated the `paddingHorizontal'` and `paddingVertical` fields in the [Stack](/docs/api/pos-ui-extensions/components/Stack) component. - Removed `customValidator` prop from the [FormattedTextField](/docs/api/pos-ui-extensions/components/formattedtextfield) component. - Removed `email`, `firstName`, `lastName`, and `note` from the [Customer](/docs/api/pos-ui-extensions/apis/cart-api#customer) object. ### Features - Added [PrintApi](/docs/api/pos-ui-extensions/apis/print-api) and a [PrintPreview](/docs/api/pos-ui-extensions/components/printpreview) component. - Added `currency` prop to the [SessionApi](/docs/api/pos-ui-extensions/apis/session-api). - [Cart API](/docs/api/pos-ui-extensions/apis/cart-api) updates: - Added `bulkUpdateCart` function for single-operation cart updates. - The `addLineItem` and `addCustomSale` functions now return a UUID for the added line item. - Added [Box](/docs/api/pos-ui-extensions/components/box) component. - Enhanced the [Stack](/docs/api/pos-ui-extensions/components/box) component. New fields include `justifyContent`, `alignItems`, and `alignContent`, as well as numerous new sizing and spacing options. - Added Sizing and fill options to the[Image](/docs/api/pos-ui-extensions/components/image) component. All of the changes are available for POS UI extensions version 2025-01 and POS app version 9.26.0. See the [version log](https://shopify.dev/docs/api/pos-ui-extensions/unstable/versions) for all version details. *Published: January 06, 2025* Tags: API, Update Link: https://shopify.dev/changelog/pos-ui-extensions-2025-01-update --- ## New Markets APIs As of `2025-04`, the Markets APIs have been updated to support additional customizations and conditions for each market, enabling merchants to tailor their shops' buyer experiences. To transition away from the "primary market" concept, a new mutation, [`backupRegionUpdate`](https://shopify.dev/docs/api/admin-graphql/2025-04/mutations/backupRegionUpdate) allows you to set a shop-wide region to use when no better option can be determined from buyer signals. Instead of `MarketRegionCreateInput`, you must use [`BackupRegionUpdateInput`](https://shopify.dev/docs/api/admin-graphql/2025-04/input-objects/BackupRegionUpdateInput). * To query the shop's backup region, use [`backupRegion`](https://shopify.dev/docs/api/admin-graphql/2025-04/queries/backupRegion). * To obtain a list of available regions that can be set as a backup, use the [`availableBackupRegions`](https://shopify.dev/docs/api/admin-graphql/2025-04/queries/availableBackupRegions) query. The [`Market.currencySettings`](https://shopify.dev/docs/api/admin-graphql/2025-04/objects/Market#field-currencysettings) field is now nullable. A null value indicates that the currency settings are inherited from the parent market. A new WebPresence type replaces `MarketWebPresence`, allowing a web presence to exist without being assigned to a market. All fields for a `WebPresence` remain the same, except for `market`, which is replaced by `markets` to indicate that a web presence can be assigned to multiple markets. *Published: January 03, 2025* Tags: API, Breaking API Change Link: https://shopify.dev/changelog/new-markets-apis --- ## New `collection_id` filter added to `products` query filters As of the **2024-10** version of the GraphQL Admin API, a new filter, `collection_id`, has been added to the `products` query. This filter allows you to retrieve products that belong to a specific collection. When using the `collection_id` filter, it can be combined with the following filters: - `created_at` - `updated_at` - `published_at` - `gift_card` - `handle` - `combined_listing_role` - `product_type` - `status` - `title` - `vendor` For more details on all available attributes for the `products` query, visit the [Shopify developer documentation](https://shopify.dev/docs/api/admin-graphql/2024-10/queries/products#argument-query) on [shopify.dev](https://shopify.dev/). Example usage of the `collection_id` filter in a query: ```graphql { products(query: "collection_id:1234567890") { edges { node { id title } } } } ``` This query retrieves products from the collection with the ID `1234567890`. *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/new-collection_id-filter-added-to-products-query-filters --- ## New fields to represent product bundles in a grouped view As of API `2025-01` version, we have introduced two new fields that allow you to accurately nest component products under the parent product in a grouped view. * The new `components` field has been added to the [AbandonedCheckoutLineItem](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/AbandonedCheckoutLineItem) object in the Admin GraphQL API. Use this field to define the component products within a product bundle, ensuring a grouped view in Abandoned Checkout Emails. * The new `group` field has been added to the [LineItem](https://shopify.dev/docs/api/customer/2025-01/objects/LineItem) object in the Customer Account API. Use this field to indicate that line item products are a part of a product bundle, ensuring a grouped view in Orders Detail Pages. In addition, these fields can help you display product bundles in a grouped view in transactional emails, such as order confirmations and shipping updates. Learn how you can implement a grouped view by following [this tutorial](https://shopify.dev/docs/storefronts/themes/product-merchandising/bundles-emails). *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/support-bundles-grouped-view-fields-in-graphql-api --- ## Filter products by category or taxonomy metafield Starting with Storefront API version 2025-01, you can now filter products within collections and search results using `CategoryFilter` and `TaxonomyMetafieldFilter`. - **`CategoryFilter`**: Filter products by a category ID. - **`TaxonomyMetafieldFilter`**: Filter products based on a taxonomy metafield namespace, key, and value. Learn more about [filtering products in collections](https://shopify.dev/docs/storefronts/headless/building-with-the-storefront-api/products-collections/filter-products) on Shopify.dev. *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/filter-products-by-category-or-taxonomy-metafield --- ## Minimum requirement is now optional on automatic discounts Previously merchants were required to specify minimum purchase conditions on product, order, and free shipping automatic discounts. We're now making these conditions optional, so the `minimumRequirement` field in our APIs is now able to return a `null` value. As of version 2025-01, the `minimumRequirement` field for both [DiscountAutomaticBasic](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/DiscountAutomaticBasic#field-minimumrequirement) and [DiscountAutomaticFreeShipping](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/DiscountAutomaticFreeShipping#field-minimumrequirement) will become nullable. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/minimum-requirement-is-now-optional-on-automatic-discounts --- ## New customer input field for the OrderCreate mutation As of GraphQL Admin API 2025-01 version, we're deprecating the `customer_id` field in favor of the new `customer` field which you can use to either associate an existing customer or upsert a customer record. This provides some added flexibility when creating an order by saving the caller an extra step in fetching the customer ID before initiating the order creation. Learn more about `orderCreate` on [Shopify.dev](https://shopify.dev/docs/api/admin-graphql/2024-10/mutations/orderCreate). *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/new-customer-input-field-for-the-ordercreate-mutation --- ## Introduce concatenatedOriginContract to subscriptionLine As of 2025-01, we've introduced `concatenatedOriginContract` to `subscriptionLine` . You can now query the origin contract of the lines if you have used the Subscription Billing Cycle APIs to combine multiple contracts. This can be accessed through `subscriptionBillingCycle.editedContract.lines.concatenatedOriginContract`. Learn more about combining contract on [Shopify.dev](https://shopify.dev/docs/apps/build/purchase-options/subscriptions/contracts/combine-subscription-contracts). *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/introduce-concatenatedorigincontract-to-subscriptionline --- ## Unused PriceListUserErrorCode values removed Starting in API version 2025-01, [PriceListErrorCode](https://shopify.dev/docs/api/admin-graphql/unstable/enums/PriceListUserErrorCode) values that are currently not returned by the API will be hidden. These error codes include: - `CONTEXT_RULE_COUNTRIES_LIMIT` - `CONTEXT_RULE_COUNTRY_TAKEN` - `CONTEXT_RULE_LIMIT_REACHED` - `CURRENCY_COUNTRY_MISMATCH` - `COUNTRY_CURRENCY_MISMATCH` - `MARKET_CURRENCY_MISMATCH` - `CONTEXT_RULE_MARKET_NOT_FOUND` - `CONTEXT_RULE_MARKET_TAKEN` *Published: January 01, 2025* Tags: API, Breaking API Change Link: https://shopify.dev/changelog/unused-pricelistusererrorcode-values-removed --- ## Update to `percentage_adjustment` field on `SellingPlanPercentagePriceAdjustment` In the Storefront API version 2025-01, there is an update to the [adjustmentPercentage](https://shopify.dev/docs/api/storefront/2025-01/objects/SellingPlanPercentagePriceAdjustment#field-adjustmentpercentage) field on the [`SellingPlanPercentagePriceAdjustment`](https://shopify.dev/docs/api/storefront/2025-01/objects/SellingPlanPercentagePriceAdjustment) object. This field, which facilitates the percentage price adjustment for a selling plan's pricing policy, will transition from an [`Int`](https://shopify.dev/docs/api/storefront/2025-01/scalars/Int) data type to a [`Float`](https://shopify.dev/docs/api/storefront/2025-01/scalars/Float). *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/update-to-percentage_adjustment-field-on-sellingplanpercentagepriceadjustment --- ## Deprecation of `storefrontCustomerAccessTokenCreate` Mutation As of API version `2025-01`, the `storefrontCustomerAccessTokenCreate` mutation is deprecated. This mutation, which was used to exchange the Customer Access Token in the `Authorization` header for a Storefront Customer Access Token, is no longer necessary. The Storefront API now directly supports Access Tokens from the Customer Accounts API via the `@inContext` [BuyerInput#customerAccessToken](https://shopify.dev/docs/api/storefront/2025-01/input-objects/BuyerInput#field-customeraccesstoken), and can be used for cart creation and buyer updates. **Migration Path:** 1. Obtain an access token using the OAuth2 specification. Detailed steps are available [here](https://shopify.dev/docs/api/customer#step-obtain-access-token). These steps are identical to those for obtaining an access token for the Customer Accounts API. 2. Use this access token directly with the Storefront API, replacing the deprecated `storefrontCustomerAccessTokenCreate` mutation. This access token identifies your customer, enabling personalized features within the Storefront API. For more information on the Customer Accounts API, visit [Shopify.dev](https://shopify.dev/docs/api/customer). *Published: January 01, 2025* Tags: API, Deprecation Announcement Link: https://shopify.dev/changelog/deprecation-of-storefrontcustomeraccesstokencreate-mutation --- ## New delivery promise participants API As of the 2025-01 Admin GraphQL API, you can now query for delivery promise participants, using [`deliveryPromiseParticipants`](https://shopify.dev/docs/api/admin-graphql/2025-01/queries/deliveryPromiseParticipants). You can make updates using the [`deliveryPromiseParticipantsUpdate`](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/deliveryPromiseParticipantsUpdate) mutation. These APIs control the usage of delivery promises on the platform. *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/new-delivery-promise-participants-api --- ## Combined Listings update mutation error improvements Starting with the Admin API version 2025-01, we've introduced new error codes for the `combinedListingUpdate` mutation. These enhancements aim to provide clearer feedback when incorrect data is submitted. - The `missing_option_values` error occurs when the `optionsAndValues` field is required but not provided in the request. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/combined-listings-update-mutation-error-improvements --- ## Update in orders webhook to view bundles and their components Starting with the Admin API version 2025-01, we have added the `sales_line_item_group_id` field to the orders webhook. This field allows you to determine if a specific `line_item` is part of a bundle. When a `line_item` belongs to a bundle, it will have an associated `sales_line_item_group_id`. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/update-in-orders-webhook-to-view-bundles-and-their-components --- ## Public apps must use new GraphQL Product APIs to be accepted in the Shopify App Store Starting January 6, 2025, all new apps submitted to the Shopify App Store must use the [new GraphQL Product APIs](https://shopify.dev/changelog/new-graphql-product-apis-that-support-up-to-2000-variants-now-available-in-2024-04). After this date, apps that query [deprecated REST API product resources](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model/api-updates#deprecated-rest-endpoints) won’t be approved. As of February 1, 2025, all public apps must migrate to the [new GraphQL Product APIs](https://shopify.dev/changelog/new-graphql-product-apis-that-support-up-to-2000-variants-now-available-in-2024-04). This includes apps already listed in the Shopify App Store. Public apps are always required to use currently supported APIs. To learn more about the specific changes to Shopify’s product APIs, and how to update your app, check out our [migration guide](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model). *Published: January 01, 2025* Tags: Shopify App Store, Update Link: https://shopify.dev/changelog/public-apps-must-use-new-graphql-product-apis-to-be-accepted-in-the-shopify-app-store --- ## Introduce a `tax_exempt` field associated to a `CompanyLocation` The `CompanyLocationTaxSettings` now also contains the `tax_exemptions` and `tax_registration_id`. As a result, we have deprecated these fields from the root of `CompanyLocation.` *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/introduce-a-tax_exempt-field-associated-to-a-companylocation --- ## New validation against duplicate handles in productCreate, productUpdate, and productSet mutation inputs As of the `2025-01` version of the Admin GraphQL API, the `handle` field in [productInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/ProductInput) for [productCreate](https://shopify.dev/docs/api/admin-graphql/latest/mutations/productCreate) and [productUpdate](https://shopify.dev/docs/api/admin-graphql/latest/mutations/productUpdate), as well as in [productSetInput](https://shopify.dev/docs/api/admin-graphql/latest/input-objects/ProductSetInput) for [productSet](https://shopify.dev/docs/api/admin-graphql/latest/mutations/productSet) will be validated for uniqueness. This means that you will no longer be able to input a duplicate handle. This change does not affect existing behaviour when `handle` is not provided as input. This enhancement ensures that there are no collisions when creating or updating product handles. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/new-validation-against-duplicate-handles-in-productcreate-productupdate-and-productset-mutation-inputs --- ## Tax and Duties are deprecated in Storefront Cart API As of API version `2025-01`, we're deprecating the [tax and duty](https://shopify.dev/docs/api/storefront/2024-01/objects/Cart#field-cost) fields in Storefront API Cart. Tax and Duties are calculated at Checkout where they can be finalized with the complete context of the buyer's information, ensuring greater accuracy. *Published: January 01, 2025* Tags: API, Deprecation Announcement Link: https://shopify.dev/changelog/tax-and-duties-are-deprecated-in-storefront-cart-api --- ## Add new requiresShippingMethod field to fulfillmentServiceCreate and fulfillmentServiceUpdate mutations As of Admin API 2025-04, we have introduced a new field `requiresShippingMethod` on the [fulfillmentServiceCreate](https://shopify.dev/docs/api/admin-graphql/2025-04/mutations/fulfillmentServiceCreate) and [fulfillmentServiceUpdate](https://shopify.dev/docs/api/admin-graphql/2025-04/mutations/fulfillmentServiceUpdate) mutations to bring these mutations in line with their REST API equivalents. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/add-new-requiresshippingmethod-field-to-fulfillmentservicecreate-and-fulfillmentserviceupdate-mutations --- ## Enhanced variant query limits for single product queries As of the **2025-01** version of the GraphQL Admin API, you can now use a limit of up to 2000 variants when running a query on a single product, such as `product` or `productByHandle`. This enhanced limit does not apply if you make multiple queries in one request, or are accessing the variants any other way except through the `variants` connection. Learn more about the [product](https://shopify.dev/docs/api/admin-graphql/2024-10/objects/Product) object on [Shopify.dev](https://shopify.dev/). *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/enhanced-variant-query-limits-for-single-product-queries --- ## Apply multiple holds to a single fulfillment order With the introduction of support for placing more than one hold per fulfillment order, you can quickly and easily add another hold each time an issue arises. With all of the reasons captured separately, you can release individual holds confidently, safe in the knowledge that all other reasons are captured in their own holds. ## Migrating to the `2025-01` GraphQL API version ### Fetch all holds for a fulfillment order As of the `2025-01` API version, the [fulfillmentOrder.fulfillmentHolds field](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/FulfillmentOrder#field-fulfillmentholds) now returns all active holds applied to a fulfillment order. ### Place multiple holds per fulfillment order As of the `2025-01` API version, the [fulfillmentOrderHold mutation](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/fulfillmentOrderHold) can now be successfully executed on fulfillment orders that are already on hold. To place multiple holds on a fulfillment order, apps need to supply the new [handle field](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/FulfillmentHold#field-handle). This field is a unique identifier for the holds placed by an app and prevents apps from inadvertently creating duplicate holds. The handle must be unique among the holds that the app has placed on a single fulfillment order. If an app attempts to place two holds with the same handle, the second hold will be rejected with [a duplicate hold user error](https://shopify.dev/docs/api/admin-graphql/2025-01/enums/FulfillmentOrderHoldUserErrorCode#value-duplicatefulfillmentholdhandle). For backward compatibility, the handle field is optional and will default to an empty string. However, a single app will not be able to place multiple holds on a fulfillment order without supplying a unique handle for each, as, by default, each hold will get the same default handle. Each app can place up to 10 active holds per fulfillment order. After this, the mutation will return [a user error indicating that the limit has been reached](https://shopify.dev/docs/api/admin-graphql/2025-01/enums/FulfillmentOrderHoldUserErrorCode#value-fulfillmentorderholdlimitreached). The app would need to release one of its existing holds before being able to apply a new one. When placing a hold on a fulfillment order that is already held, the [fulfillmentHold.fulfillmentOrderLineItems input field](https://shopify.dev/docs/api/admin-graphql/2025-01/input-objects/FulfillmentOrderHoldInput#field-fulfillmentorderlineitems) should not be supplied. If this field is supplied, [a user error will be returned indicating that the fulfillment order is not able to be split](https://shopify.dev/docs/api/admin-graphql/2025-01/enums/FulfillmentOrderHoldUserErrorCode#value-fulfillmentordernotsplittable). The [fulfillmentOrder.supportedActions](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/fulfillmentorder#field-supportedactions) field will now return the [HOLD](https://shopify.dev/docs/api/admin-graphql/2025-01/enums/FulfillmentOrderAction#value-hold) action when a fulfillment order is on hold and an additional hold can be added. ### Supply hold id's when releasing holds *(highly recommended)* It is highly recommended that all apps that release holds specify the hold IDs when releasing. [Support for releasing holds by id was introduced in the 2024-10 API version](https://shopify.dev/changelog/fulfillment-holds-now-able-to-be-released-by-id). Releasing all holds on a fulfillment order without supplying the hold IDs will result in the fulfillment order being released prematurely and items being incorrectly fulfilled. ### Listen for individual holds being placed and released webhooks As of the `2025-01` API version, two new webhook topics are available for the fulfillment hold resource: [fulfillment_holds/added](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_holds/added) and [fulfillment_holds/released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_holds/released). The new webhooks will be emitted each time a hold is placed and released. ### Continue to listen for fulfillment orders being held and released using existing webhooks The [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) and [fulfillment_orders/hold_released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/hold_released) topics will continue to be emitted in the same way as before. - The [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) webhook is emitted when a fulfillment order transitions to the `ON_HOLD` status. - The [fulfillment_orders/hold_released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/hold_released) webhook is emitted when a fulfillment order is released from all holds and is no longer on hold. As of the `2025-01` API version, now that a fulfillment order can have multiple holds, the `fulfillment_order.fulfillment_holds` field in the [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) webhook payload can now return multiple holds. ## Using GraphQL API versions prior to 2025-01 ### Continue to get the first hold placed on a fulfillment order The [fulfillment holds field on a fulfillment order](https://shopify.dev/docs/api/admin-graphql/2024-10/objects/FulfillmentOrder#field-fulfillmentholds) will continue to return an array of a single hold. If multiple holds exist on the fulfillment order, the oldest active hold will be returned. Once this hold is released, the next earliest will be returned until no holds remain. ### Continue to place a single hold per fulfillment order The [fulfillmentOrderHold mutation](https://shopify.dev/docs/api/admin-graphql/2024-10/mutations/fulfillmentOrderHold) will continue to only support placing a single hold per fulfillment order. If an app attempts to place a hold on a fulfillment order that is already being held, the same error will be returned as was previously returned. It will be a user error with a message saying "`Cannot apply a fulfillment hold on a fulfillment order in an uninterruptible state.`". ### Continue to release all holds from a fulfillment order *(discouraged)* The [fulfillmentOrderReleaseHold mutation](https://shopify.dev/docs/api/admin-graphql/2024-10/mutations/FulfillmentOrderReleaseHold) will continue to release the fulfillment order from being held by releasing it from all holds at once if no hold IDs are supplied. It is highly recommended that all apps which release holds migrate to using the `2024-10` API version or newer, so that they can selectively release holds by ID by specifying the [holdIds](https://shopify.dev/docs/api/admin-graphql/2024-10/mutations/FulfillmentOrderReleaseHold#argument-holdids) mutation argument. Releasing all holds on a fulfillment order without supplying the hold IDs will result in the fulfillment order being released prematurely and items being incorrectly fulfilled. ### Continue to listen for fulfillment orders being held and released using existing webhooks The [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) and [fulfillment_orders/hold_released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/hold_released) topics will continue to be emitted in the same way as before. - The [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) webhook is emitted when a fulfillment order transitions to the `ON_HOLD` status. - The [fulfillment_orders/hold_released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/hold_released) webhook is emitted when a fulfillment order is released from all holds and is no longer on hold. The `fulfillment_order["fulfillment_holds"]` field in the webhooks payload will continue to return an array of a single hold. If multiple holds exist on the fulfillment order, the oldest active hold will be returned. ## Using the REST API to interact with holds *(discouraged)* The REST API will not support multiple holds per fulfillment order. Apps should migrate to using the GraphQL API if they wish to use this feature. ### Continue to get the first hold placed on a fulfillment order The [fulfillment holds attribute on the fulfilment order resource](https://shopify.dev/docs/api/admin-rest/2025-01/resources/fulfillmentorder) will continue showing only the one oldest active hold under scenarios of multiple holds. Once this hold is released, the next earliest will be returned until no holds remain. ### Continue to place a single hold per fulfillment order The [hold endpoint](https://shopify.dev/docs/api/admin-rest/2025-01/resources/fulfillmentorder#post-fulfillment-orders-fulfillment-order-id-hold) will continue to only support placing a single hold per fulfillment order. If an app attempts to place a hold on a fulfillment order that is already being held, the same error will be returned as was previously returned. ### Continue to release all holds from a fulfillment order *(discouraged)* The [release hold endpoint](https://shopify.dev/docs/api/admin-rest/2025-01/resources/fulfillmentorder#post-fulfillment-orders-fulfillment-order-id-release-hold) will continue to release the fulfillment order from being held by releasing it from all holds at once. It is highly recommended that all apps which release holds migrate to using the [fulfillmentOrderReleaseHold mutation](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/FulfillmentOrderReleaseHold), so that they can selectively release holds by ID. Releasing all holds on a fulfillment order without supplying the hold IDs will result in the fulfillment order being released prematurely and items being incorrectly fulfilled. ### Continue to listen for fulfillment orders being held and released using existing webhooks The [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) and [fulfillment_orders/hold_released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/hold_released) topics will continue to be emitted in the same way as before. - The [fulfillment_orders/placed_on_hold](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/placed_on_hold) webhook is emitted when a fulfillment order transitions to the `ON_HOLD` status. - The [fulfillment_orders/hold_released](https://shopify.dev/docs/api/webhooks?reference=toml#list-of-topics-fulfillment_orders/hold_released) webhook is emitted when a fulfillment order is released from all holds and is no longer on hold. The `fulfillment_order["fulfillment_holds"]` field in the webhooks payload will continue to return an array of a single hold. If multiple holds exist on the fulfillment order, the oldest active hold will be returned. ## Learn more Learn more about [putting an order's fulfillment on hold](https://help.shopify.com/en/manual/fulfillment/fulfilling-orders/holding-fulfillments). *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/apply-multiple-holds-to-a-single-fulfillment-order --- ## Change to FulfillmentOrderSortKeys Starting in API version 2025-01, RELEVANCE will be removed as a valid value from [FulfillmentOrderSortKeys](https://shopify.dev/docs/api/admin-graphql/2024-10/enums/FulfillmentOrderSortKeys) in the GraphQL Admin API. *Published: January 01, 2025* Tags: API, Deprecation Announcement Link: https://shopify.dev/changelog/change-to-fulfillmentordersortkeys --- ## New customer's webhook and changes to existing customer's webhooks payload As of 2025-01, we're changing how a customer is represented in webhooks: * We added the `customers/purchasing_summary` webhook. * We made some changes affecting webhooks containing a customer payload: * We removed `tags` in favour of the `customer.tags_added` and `customer.tags_removed` webhooks. * We removed `email_marketing_consent` in favour of the `customers/email_marketing_consent_update`. * We removed `sms_marketing_consent` in favour of the `customers/marketing_consent_update`. * We removed the following fields: `last_order_id`, `last_order_name`, `total_spent`, and `orders_count`. They are now available in the new `customers/purchasing_summary` webhook. The webhooks containing a customer payload are the following: * `checkouts/create` * `checkouts/update` * `customers/create` * `customers/delete` * `customers/disable` * `customers/enable` * `customers/update` * `draft_orders/create` * `draft_orders/update` * `orders/cancelled` * `orders/create` * `orders/fulfilled` * `orders/paid` * `orders/partially_fulfilled` * `orders/updated` Learn more about webhook topics on [Shopify.dev](https://shopify.dev/docs/api/admin-graphql/2025-01/enums/WebhookSubscriptionTopic). *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/new-customer-s-webhook-and-changes-to-existing-customer-s-webhooks-payload --- ## Link any product metafields of type list.metaobject to product options Up until now, merchants had the ability to link their options to category metafields, allowing them to use these option values across similar products. This release expands that functionality to include any metaobject reference list. More details about this update can be found at [Shopify.dev](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model/metafield-linked). *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/link-any-product-metafields-of-type-list-metaobject-to-product-options --- ## Admin access input is now optional when setting metafield definition access When creating or updating a metafield definition's `access` the `admin` field is now optional. When `admin` is not explicitly set, it will default the same way it is when the entire `access` field is omitted. Learn more about metafield access controls on [Shopify.dev](https://shopify.dev/docs/apps/build/custom-data/metafields/definitions/use-access-controls-metafields) *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/admin-access-input-is-now-optional-when-setting-metafield-definition-access --- ## Support `Delayed` Fulfillment Status in GraphQL API As of Admin API 2025-01, we have officially introduced a new [fulfillment event status](https://shopify.dev/docs/api/admin-graphql/2024-10/enums/FulfillmentEventStatus) called `delayed`. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/support-delayed-fulfillment-status-in-graphql-api --- ## ReverseFulfillmentOrder.order field is nullable as of 2025-01 As of **2025-01**, ReverseFulfillmentOrder.order field is nullable. An Order can be nullable if the client does not have access to the [`read_all_orders`](https://shopify.dev/docs/api/usage/access-scopes#orders-permissions) scope and the order is older than 60 days or no longer exists. For versions that predate **2025-01**, the order field will return a graphql error when the order is not available. Learn more about ReverseFulfillmentOrder on [Shopify.dev](https://shopify.dev/docs/api/admin-graphql/unstable/objects/ReverseFulfillmentOrder). *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/reversefulfillmentorder-order-field-is-nullable-as-of-2025-01 --- ## Inventory set on hand quantities mutation removal As of Admin API **2025-04**, we are removing the `inventorySetOnHandQuantities` mutation. Instead, you can set `available` and `on_hand` quantities for inventory by using the [`inventorySetQuantities` mutation](https://shopify.dev/docs/api/admin-graphql/2024-07/mutations/inventorySetQuantities). *Published: January 01, 2025* Tags: API, Deprecation Announcement Link: https://shopify.dev/changelog/inventory-set-on-hand-quantities-mutation-removal --- ## Addition of 'paymentDetails' field in `verificationSessionResolve` mutation. As of Payments Apps API version **2025-01** release, the `paymentDetails` field will be addded to `verificationSessionResolve` mutation. Payment providers can now send payment details like Card Information etc. as an argument. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/addition-of-paymentdetails-field-in-verificationsessionresolve-mutation --- ## BXGY discount support for subscriptions As of 2025-01, Buy X Get Y (BXGY) discounts support subscriptions, only in cases where X is a subscription and Y is a one-time purchase item at a discounted price or a free item. You can use the [discountAutomaticBxgyCreate](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/discountAutomaticBxgyCreate) or [discountCodeBxgyCreate](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/discountCodeBxgyCreate) mutations to create a new BXGY discount, or the [discountAutomaticBxgyUpdate](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/discountAutomaticBxgyUpdate) or [discountCodeBxgyUpdate](https://shopify.dev/docs/api/admin-graphql/2025-01/mutations/discountCodeBxgyUpdate) mutations to update an existing BXGY discount. Use the isOneTimePurchase and isSubscription fields on [DiscountCustomerBuysInput](https://shopify.dev/docs/api/admin-graphql/2025-01/input-objects/DiscountCustomerBuysInput) to specify which items can be discounted. Learn more [building discounts with GraphQL Admin API](https://shopify.dev/docs/apps/build/discounts#build-with-the-graphql-admin-api). *Published: January 01, 2025* Tags: API, New Link: https://shopify.dev/changelog/bxgy-discount-support-for-subscriptions --- ## Introduce 3DS support for verifications As of version `2025-01`, payments extensions that support vaulting will now be able to process 3DS challenges for verifications. That is possible through : - A new mutation, `VerificationSessionRedirect` - New arguments to the existing `VerificationSessionResolve` and `VerificationSessionReject` mutations. If 3DS is required for a verification, you must use the `VerificationSessionRedirect` mutation. When resolving or rejecting a verification that required 3DS, pass the authentication argument to either the `VerificationSessionResolve` or `VerificationSessionReject` mutation. We're also deprecating the following `VerificationSessionStateReason`: `REQUIRED_3DS_CHALLENGE` . Use the new `VerificationSessionRedirect` mutation instead. For payments extensions that support vaulting, we strongly recommend you to update it to the `2025-01` version as soon as possible. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/introduce-3ds-support-for-verifications --- ## Fulfillment Hold Access Update For Node Queries As of the Admin API version 2025-01, apps using the [node or nodes GraphQL queries](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/FulfillmentHold#interface-node) to fetch fulfillment holds will only be able to fetch those that belong to a fulfillment order that they have access to. If your app has the `read_merchant_managed_fulfillment_orders` scope, you will be able to access holds on fulfillment orders assigned to a merchant managed location. If your app has the `read_assigned_fulfillment_orders` scope, you will be able to access holds on fulfillment orders assigned to locations belonging to your app. If your app has the `read_third_party_fulfillment_orders` scope, you will be able to access holds on fulfillment orders assigned to a third party location. If your app has the `read_marketplace_fulfillment_orders` scope, you will be able to access holds on fulfillment orders which belong to one of your marketplace's orders. ### How will this change effect my app? This change will only effect apps which fetch fulfillment holds using a [node or nodes GraphQL query](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/FulfillmentHold#interface-node) using the Admin API. If your app does not currently have sufficient access scopes as defined above then you will need to request the correct access scopes before migrating to the 2025-01 API version. When using a [node or nodes query](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/FulfillmentHold#interface-node) to fetch a holds, if your app does not have sufficient access to access the hold then `null` will be returned for any holds that you do not have access to. See the [fulfillment hold resource](https://shopify.dev/docs/api/admin-graphql/2025-01/objects/FulfillmentHold) for more information on what scopes are required. See the API access scopes section of [the FulfillmentOrder resource](https://shopify.dev/docs/api/admin-graphql/2024-10/objects/FulfillmentOrder) for more information about these scopes. *Published: January 01, 2025* Tags: API, Update Link: https://shopify.dev/changelog/fulfillment-hold-access-update-for-node-queries --- ## Cart Delivery Address Management We've refined and improved how delivery addresses are handled by making `deliveryAddresses` a required input field within a new delivery object. As of API version 2025-01, the [`deliveryAddressPreferences`](https://shopify.dev/docs/api/storefront/2025-01/objects/CartBuyerIdentity#field-deliveryaddresspreferences) field on the `CartBuyerIdentity` object is deprecated. Use the new [`addresses`](https://shopify.dev/docs/api/storefront/2025-01/objects/CartDelivery#field-addresses) field on the `CartDelivery` object instead. We've added the following new mutations for managing delivery addresses on carts: * [`cartDeliveryAddressesAdd`](https://shopify.dev/docs/api/storefront/2025-01/mutations/cartDeliveryAddressesAdd) * [`cartDeliveryAddressesUpdate`](https://shopify.dev/docs/api/storefront/2025-01/mutations/cartDeliveryAddressesUpdate) * [`cartDeliveryAddressesRemove`](https://shopify.dev/docs/api/storefront/2025-01/mutations/cartDeliveryAddressesRemove) For cart delivery addresses, you can set an address as `selected` to indicate that delivery rates should be calculated. This improves performance by avoiding unnecessary rate generation. It also ensures that addresses are synchronized between Checkout and Cart, maintaining a single source of truth for any updates or changes. We recommend reviewing your current integration and preparing to adopt the new field and mutations. *Published: January 01, 2025* Tags: API, Deprecation Announcement Link: https://shopify.dev/changelog/cart-delivery-address-management --- ## Updates effective December 30 to our Partner Program Agreement and API License and Terms of Use EFFECTIVE DECEMBER 30, 2024 **ACTION REQUIRED** We've made changes to our [Partner Program Agreement](https://www.shopify.ca/partners/terms?shpxid=823b80d5-C747-48F6-6CF0-832254EC6F4B) and [API License and Terms of Use](https://www.shopify.com/legal/api-terms?shpxid=823b80d5-C747-48F6-6CF0-832254EC6F4B). These updates include terms that are intended to support the growth of Shopify Partners and Merchants, while maintaining the security and integrity of products and services offered on our platform. These changes come into effect as of today, December 30, 2024. Updates to Theme Revenue Share are effective January 1, 2025. Continued use of Shopify services on or after Monday, December 30, 2024 confirms that you’ve read, understood, and accepted these new terms. For more information and frequently asked questions, please visit the [Shopify Help Center](https://help.shopify.com/en/partners/ppa-api-faq?shpxid=823b80d5-C747-48F6-6CF0-832254EC6F4B). *Published: December 30, 2024* Tags: Shopify App Store, New Link: https://shopify.dev/changelog/updates-effective-december-30-to-our-partner-program-agreement-and-api-license-and-terms-of-use --- ## Updated requirement: Draft apps must not make calls to APIs that will be deprecated in 90 days or less Starting January 6, 2025, draft apps that make calls to APIs that will be deprecated in 90 days or less will not be able to submit their apps for review. This is an updated requirement. Be sure to check your API Health report in your Partner Dashboard to ensure your app is querying supported APIs. Public apps are always required to use currently supported APIs. To learn more about the specific changes to Shopify’s product APIs, and how to update your app, check out our [migration guide](https://shopify.dev/docs/apps/build/graphql/migrate/new-product-model). *Published: December 19, 2024* Tags: Shopify App Store, Update Link: https://shopify.dev/changelog/updated-requirement-draft-apps-must-not-make-calls-to-apis-that-will-be-deprecated-in-90-days-or-less ---