Real-time tracking of breaking changes, schema diffs, field removals, and deprecation announcements for standard API vendors.
Stripe is sunsetting legacy /v1/charges POST endpoint in favor of /v1/payment_intents. Requests using charges API will fail after 2026-09-01.
Passing access_token as a URL query parameter will be disabled permanently on 2026-08-30. Authorization header required.
Passing access_token as a URL query parameter will be disabled permanently on 2026-08-30. Authorization header required.
Stripe is sunsetting legacy /v1/charges POST endpoint in favor of /v1/payment_intents. Requests using charges API will fail after 2026-09-01.
AI assisted shortcuts in the Neon Docs. Copy page in the header opens a menu on every Neon Docs page copy the page as Markdown, or open it in ChatGPT or Claude ...
Postgres 18 is generally available. Postgres 18 is now generally available on Neon. The preview limitations have been lifted, and Postgres 18 is fully supported...
We'd like to update our previous announcement regarding classic app deprecation. We're pushing the deprecation date for classic apps to November 16, 2026.
We want to update you about our previous announcement regarding support for the files.upload API method. After much consideration and feedback, we have decided to push back the deprecation date to November 12, 2025.
Our Web API method files.upload is now deprecated and will retire on March 11, 2025. Learn how to use our new asynchronous upload flow and migrate your apps and integrations.
We want to let you know about some upcoming changes to support for legacy custom bots and classic apps on the Slack platform. Beginning March 31, 2025, we will discontinue support for legacy custom bots. For your integrations to continue working, you must create brand new Slack apps. In September 2025 March 2026, November 2026 we will discontinue support for classic apps. For your apps to continue working, you will need to migrate them to Slack apps. Any custom bots or classic apps you have built will no longer work after these dates. Refer to this changelog article for more details.
We want to update you about our previous announcement regarding support for legacy custom bots and classic apps. After much consideration and feedback, we have decided to push back the deprecation date for classic apps by 6 months: we will now discontinue support for them on March 31, 2026. Nothing will change for legacy custom bots, of which the original deprecation date was March 31, 2025.
We previously mentioned that we had deprecated the deno command and removed its listing from the help command. We have now removed the deno command completely. Developers who were depending on this command should now use the deno executable directly. We've also removed support for the deprecated, pre-release Deno Slack SDK versions that used slack.yaml and project.ts files. The Run-on-Slack platform no longer supports the slack.yaml file format, and no production projects should be affected. The project.ts file was deprecated by the Deno Slack SDK in favor of manifest.ts and manifest.json files.
We want to update you about our previous announcement regarding support for classic apps. After much consideration and feedback, we have decided to push back the deprecation date to May 25, 2026.
Retiring of api.slack.com: as previously announced, the Slack platform and developer tools documentation are moving: the Slack platform documentation is now in beta on docs.slack.dev, and the developer tools documentation has moved to its new home on tools.slack.dev. Our next step is to sunset the old documentation experience on api.slack.com, and we plan to do so by the end of June 2025. In the meantime, you may want to update any bookmarks you have pointing to api.slack.com—but not to worry, we'll have redirects in place to make sure you end up right where you need to be!
The 2026-07 release replaces a collection’s single ruleSet with a multi-source model in the GraphQL Admin API. Each collection now has one or more CollectionSource objects that define typed inclusion and exclusion conditions, plus manual selections. Shopify Functions also gain variant-level collection membership fields on the ProductVariant type. In API version 2026-07 and later, collections that use the new sources model are returned from collections queries, collection(id:) lookups, and other collection-returning fields. In earlier API versions, those same collections using new features are filtered out because the legacy ruleSet shape can’t represent them. Migrate to the 2026-07 API version to see and manage all collections in a shop. These changes are non-breaking: deprecated members remain queryable in 2026-07 so you can migrate incrementally. What’s new in the GraphQL Admin API Collection sources and conditions A new Collection.sources field returns one or more sources that back the collection. Two concrete types implement the new CollectionSource interface: • CollectionConditionsSource: includes products through typed inclusion conditions plus manual selections, and can optionally exclude products through exclusion conditions. Each source must target either PRODUCTS or VARIANTS, set by the new CollectionSourceTargetType enum. • CollectionSubCollectionsSource: pulls membership from one or more referenced collections. Conditions are strongly typed: each condition uses a concrete type with a matching input type. Exclusion conditions include a subset of inclusion conditions or use a collection-based exclusion condition to target specific collections. Matching behavior for a set of conditions is controlled by the new CollectionConditionMatchType enum: ANY means at least one condition must match; ALL means every condition must match. To define sources on a collection, collectionCreate and collectionUpdate now accept a collection argument typed as the new CollectionCreateInput or CollectionUpdateInput. CollectionUpdateInput exposes sourcesToCreate, sourcesToUpdate, and sourcesToDelete so you can update sources incrementally without replacing the entire collection definition. Shareable app collection sources A CollectionConditionsSource whose shareable field is true is owned by the calling app and can be linked to many of the shop’s collections. Use three new mutations to manage these shareable sources, and two new top-level queries to discover them: • collectionConditionsSourceCreate, collectionConditionsSourceUpdate, and collectionConditionsSourceDelete manage an app's own shareable sources. • collectionConditionsSources(appId:) returns the shareable sources owned by a specific app. • collectionConditionsSourcesByApp paginates the apps that publish shareable sources for the shop. To attach a shareable source to a specific collection, use CollectionShareableSourceInput { sourceId } inside the sources or sourcesToCreate field of the collection’s create or update input. Only the owning app can update or delete its shareable sources. Deleting a shareable source automatically detaches it from every collection that links to it. Use shareable sources only when the same logic should be reused across multiple collections. If not, use collection mutations to create, update, or delete sources. Other additions • Collection.subCollectionEligibility returns separate inclusion and exclusion eligibility states for using the collection as a sub-collection target, with a stable SubCollectionIneligibleReason enum. • collectionConditionMetafieldDefinitions returns the metafield definitions that can be used in inclusion conditions, scoped to the calling app's access. • CollectionSourceExclusionConditionUpdateInput gains a collection field, so you can update a collection-based exclusion condition in place instead of deleting and recreating it. Variant-level collection membership in Shopify Functions The ProductVarianttype in Shopify Functions gains two new fields: • inAnyCollection(ids: [ID!]!): Boolean! returns true when the variant is in any of the specified collections. • inCollections(ids: [ID!]!): [CollectionMembership!]! returns per-collection membership for the variant. A variant is a member of a collection when the variant itself is included in that collection. Existing Product.inAnyCollection and Product.inCollections continue to return true when the full product is in any of the specified collections, regardless of variant-level membership. Deprecations • Collection.ruleSet is deprecated in favor of Collection.sources. Each ruleSet rule has an equivalent inclusion condition (for example, a tag rule maps to CollectionSourceInclusionConditionProductTag). Sub-collections, exclusion conditions, and multiple sources aren’t supported in the legacy shape. • collectionCreate(input:) and collectionUpdate(input:) are deprecated in favor of collectionCreate(collection:) and collectionUpdate(collection:). The legacy input argument continues to accept CollectionInput (with its ruleSet field), but only the new collection argument can define sources. If both arguments are supplied, the collection argument takes precedence. • If your app reads Collection.ruleSet or writes input.ruleSet, switch to Collection.sources and the new collection argument. The legacy shape can’t express multiple sources, exclusion conditions, or shareable sources, and collections that use those features are filtered out of pre-2026-07 query results. • If your Function needs variant-level collection membership, call inAnyCollection or inCollections on ProductVariant. The existing Product.inAnyCollection and Product.inCollections fields continue to return product-level membership.
Starting today, metafields stored on the app resource must have a metafield definition and customer accounts permissions to be accessible through the Customer Account API. Going forward, when calling the Customer Accounts API, app metafields without a definition will no longer return a value. If your app has functionality which depends on these fields, update those metafields to use definitions with the Customer Account API permission to avoid disruption. Action required: You must ensure that every metafield your app uses for customer account UI extensions, a Hydrogen or a Headless store, has a definition. • Run the metafieldDefinitionCreate for every store that installs your app to ensure the metafields are correctly defined. • For app-owned metafields, configure declarative metafields in your app’s TOML file. • Configure the access settings on your definition to allow customer accounts API access. Metafields owned by Customer or Order resources will not be affected by this change.
The discountedUnitPrice field on the DraftOrderLineItem object in the Customer Account API is now deprecated. Use approximateDiscountedUnitPrice instead. This new field calculates the discounted total divided by the quantity, resulting in an approximate per-unit price reduction. Update your queries to use approximateDiscountedUnitPrice.
In February 2026, we introduced the shopify-account component, which lets customers sign in and manage their account directly on the storefront. It supports passwordless sign-in, automatic Sign in with Shop recognition, and social sign-in providers. Once signed in, customers can reach their account pages from the account menu. As of today, all new themes and updates to existing themes submitted to the Shopify Theme Store must include the component in their header, visible on both desktop and mobile, so customers get a consistent experience on any device. Additionally, legacy customer accounts have been deprecated, and themes are no longer required to include legacy customer account template files. Learn more: • shopify-account component developer docs • Theme store requirements — features • Legacy customer accounts are deprecated
POS UI Extensions 2026-07 introduces the Printing API (shopify.printing), which enables extensions to discover hardware printers with getPrinters() and send documents directly to a connected receipt printer with print(). The Printing API supersedes shopify.print, which is now deprecated. No immediate action is required; plan to migrate when you adopt 2026-07. What changed • shopify.printing.getPrinters() returns the hardware printers available to the device. Each printer includes an id, name, and connected status. • shopify.printing.print(src, options?) prints the document at src. If you omit options.printer, the system print dialog opens. If you pass a printer returned by getPrinters(), the document prints directly to that printer with no dialog. The src must be either a relative path appended to your app’s application_url, or a full URL on the same origin. The document is fetched using the extension’s session token. Receipt printers can render HTML and images directly. PDFs require the system print dialog: if you pass a printer when src points to a PDF, shopify.printing.print throws an error. For PDFs, always omit options.printer and rely on the system print dialog. Previously, shopify.print could only open the system print dialog, which cannot target dedicated receipt printers. Earlier POS UI Extensions API versions are unchanged. Note: Hardware printer discovery requires Shopify POS version 11.11.0 or later. On earlier versions, getPrinters() returns an empty array, even when a receipt printer is paired. This does not affect the system print dialog, which remains available. Always handle the empty-array case by falling back to the system print dialog. This also covers merchants without a receipt printer: const printers = await shopify.printing.getPrinters(); const receiptPrinter = printers.find((printer) => printer.connected); if (receiptPrinter) { await shopify.printing.print('/print/receipt', {printer: receiptPrinter}); } else { await shopify.printing.print('/print/receipt'); } The Printing API is available on all POS UI extension targets. To verify direct printing, test on a development store with POS 11.11.0 or later and a paired receipt printer. Call shopify.printing.print with a printer from getPrinters(); if the job prints without a dialog, direct printing is working. Related docs • Printing API reference • Print API reference (deprecated)
Starting in API version 2026-10, the GraphQL Admin API returns an error when a query filters by a metafield that isn't set up for filtering, instead of silently returning incorrect results. This is a breaking change. It affects apps that filter resources by metafield on version 2026-10 or later, and you'll need to update affected queries before you upgrade. What changed In API version 2026-10 and later, the GraphQL Admin API checks metafield filters before it runs a query. If a query filters by a metafield that can't be used for filtering, the query returns an error explaining the problem instead of ignoring the invalid predicate and returning an incorrect result. A metafield filter commonly fails when: • The metafield doesn't have a definition. • The metafield's definition isn't configured to allow filtering. • The metafield's type doesn't support the filter or comparison you used. Previously, invalid predicates in metafield filters were silently ignored, so a query with an invalid filter could return misleading results. Now the response tells you the filter is the problem, so you can correct it. Who's affected This change affects apps and integrations that filter by metafields in the GraphQL Admin API (for example, filtering products, orders, or customers by a metafield) on API version 2026-10 or later. Queries on version 2026-07 and earlier keep the previous behavior and aren't affected until you upgrade. You're affected only when a query filters by a metafield that isn't valid for filtering. Queries that filter by metafields set up for filtering, using a supported comparison, behave exactly as before and return the same results. Why this matters Silently returning incorrect results made invalid metafield filters hard to catch: a mistyped or unsupported filter looked identical to a query that simply had different matches. Returning an error instead lets you find and fix these problems during development, rather than shipping a filter that quietly returns nothing in production. Breaking changes and migrations API version 2026-10 is scheduled for release on October 1, 2026. Once you make requests on 2026-10 or later, a query that filters by a metafield that isn't set up for filtering returns an error instead of an empty result. To migrate: • Find the queries in your app that filter by metafields in the GraphQL Admin API. • For each one, confirm the metafield has a definition, the definition allows filtering, and the comparison you use is supported for that metafield's type. • Update any filter that references a metafield that isn't set up for filtering. • Test your queries against version 2026-10 and confirm they return results without an error. If a metafield you rely on can't be filtered yet, keep those queries on version 2026-07 or earlier until you've updated your app, and set up the metafield definition for filtering before you upgrade.
Trust is foundational to the Shopify Partner ecosystem. Partners take actions across Shopify that can directly affect merchants, and merchants need confidence when granting access to their stores. We’re introducing identity verification for partners to help protect merchants, reduce abuse, and make it harder for bad actors to operate, while creating a better experience for legitimate partners. What changed Starting today, Shopify Partners can complete identity verification before requesting collaborator access to merchant stores. Identity verification is optional today and will become mandatory in the coming weeks before sending a new collaborator request. For this launch: • Identity verification applies to sending new collaborator requests. Every user in your partner organization sending a new collaboration will need to verify their identity. • Identity verification isn’t required just to access collaborator shops where a merchant has already granted access. • Verification is completed through Stripe and requires a government-issued photo ID and a selfie or liveness check. We’re starting with collaborator requests because collaborator access is one of the clearest trust moments between merchants and partners. When a merchant approves a collaborator request, they’re giving a partner access to a live store. Action required If you or anyone in your partner organization sends collaborator requests, complete identity verification on the Request collaborations page in the Dev Dashboard. Identity verification is optional today, but we recommend completing it now to avoid interruption when it becomes mandatory in the coming weeks. After enforcement begins, unverified users won’t be able to send new collaborator requests until they complete verification. To prepare: • Complete identity verification before sending new collaborator requests. • Make sure every user in your partner organization who requests collaborator access verifies their own identity. • Have a government-issued photo ID ready, along with access to a device that can complete a selfie or liveness check. • Review the related docs below for more context on identity verification and collaborator access. Related docs • Verifying your identity as a Shopify Partner • Collaborator requests: Information shared with merchants
As of Customer Account API version 2026-10, the deprecated Customer.lastIncompleteCheckout field is removed. This also removes the now-unreachable Customer Account API Checkout type subtree, including: • Checkout • Checkout.appliedGiftCards • AppliedGiftCard • AvailableShippingRates • CheckoutLineItem • CheckoutLineItemConnection • CheckoutLineItemEdge • ShippingRate The Customer.lastIncompleteCheckout field was previously deprecated and returned null. This change removes stale Checkout Classic schema from the Customer Account API. Action required If your app queries Customer.lastIncompleteCheckout or any nested fields on the returned Checkout object, update your queries before upgrading to API version 2026-10. Remove selections such as: customer { lastIncompleteCheckout { id appliedGiftCards { id } } } There is no replacement field in the Customer Account API. If you need active cart or checkout state for a buyer storefront experience, use Storefront API cart flows instead. If you need completed customer purchase history, use the Customer Account API Customer.orders field.
Starting in version 2026-07, the useBuyerJourneyIntercept hook on checkout UI extensions, and the block_progress capability it depends on, are deprecated. Existing extensions will continue to work on current and prior API versions, but this API will be removed in a future version, so you should plan to migrate. The following are deprecated: • useBuyerJourneyIntercept (Preact hook) in checkout UI extensions • The block_progress capability in the extension’s shopify.extension.toml configuration file If you currently use useBuyerJourneyIntercept to enforce merchant business rules, migrate to a cart and checkout validation Function. These Functions run server-side and apply your rules consistently across all checkout surfaces, including express wallets and agentic checkout. If you use useBuyerJourneyIntercept to reject discount codes, migrate that logic to the discount Function API, which now supports rejecting discount codes with a custom message. To learn more and if you've got a use case that's keeping you from moving to Shopify Functions: https://community.shopify.dev/t/the-buyer-journey-intercept-api-is-now-deprecated/35930.
The isCumulative argument to the marketingEngagementCreate mutation is being deprecated, defaulting to false. Please update your integration to send non-cumulative engagements, as needed. Existing activities that have been sending cumulative metrics can migrate to non-cumulative at any time.
Starting in API version 2026-07, sales channel apps can use order attribution definitions to identify the source that created an order. Order attribution definitions are useful when your sales channel app needs attribution that is more specific than the app or channel itself. For example, you can attribute orders to a marketplace, region, account, or surface. Apps that only need default app or channel attribution don’t need to make any changes. What’s new Sales channel apps can now: • Create channel-based attribution definitions when creating channel connections. • Define static attribution sources with the order_attribution_config extension. • Create or update attribution definitions with the orderAttributionDefinitionUpsert mutation. • Query attribution definitions with the orderAttributionDefinitions query. • Delete attribution definitions with the GraphQL Admin API. • Pass an attribution definition handle when creating orders with orderCreate. • Pass an attribution definition handle through source_name when creating carts with the Storefront API cartCreate mutation or when using cart permalinks. • Read resolved attribution details with Order.attribution. To use order attribution definitions, your app must be a sales channel app with a channel_config extension. What you need to do If your app needs attribution that is more specific than app-level or channel-level attribution, create order attribution definitions and pass the definition handle in sourceName when creating carts or orders. If sourceName doesn’t match an approved order attribution definition, Shopify falls back to app-only attribution. Use Order.attribution for new attribution reads. Order.channelInformation remains available, but is deprecated.
Starting with GraphQL Admin API version 2026-10, creating a carrier service no longer automatically adds it to the shop’s General shipping profile. This breaking change affects carrier services created using: • GraphQL Admin API: carrierServiceCreate • REST Admin API: POST /admin/api/{version}/carrier_services.json Previously, active API carrier services created through these APIs were automatically added to eligible shipping zones in the shop’s General shipping profile. In API version 2026-10 and later, creating a carrier service only registers the carrier service. Shopify no longer adds that carrier service to the General shipping profile or any of its shipping zones by default. If your app relies on the previous behavior where creating a carrier service automatically made rates available to merchants, you must update your integration so that rates are explicitly configured. Without these additional steps, merchants won’t see rates from newly created carrier services at checkout. After creating a carrier service, you must ensure that its rates are added to a shipping profile by either: • (Recommended) Directing merchants to manually add the carrier-calculated rate to the appropriate shipping profile in the Shopify admin. • Programmatically adding the carrier-calculated rate to the appropriate shipping profile using the shipping profile APIs. Older supported API versions will continue to use the existing automatic-add behavior for carrier services in the General shipping profile until those versions are sunset. Learn more about carrierServiceCreate and the CarrierService REST resource.
What's changing The cart tools on the Storefront MCP server are being deprecated in favour of the UCP-conforming Cart MCP tools: • get_cart and update_cart on https://{shop}.myshopify.com/api/mcp are deprecated. Cart MCP implements the UCP cart capability (dev.ucp.shopping.cart, version 2026-04-08) and exposes the following tools at the https://{shop-domain}/api/ucp/mcp endpoint: • create_cart: Create a new cart with line items and optional buyer context. • get_cart: Retrieve the current state of a cart. • update_cart: Replace the cart's contents. • cancel_cart: Cancel a cart. The deprecated tools will be maintained until August 31, 2026, but all documentation will refer to the Cart MCP tools. What you should do If you're building with the Storefront MCP cart tools: • Migrate get_cart and update_cart calls to the Cart MCP tools, and update endpoints to use https://{shop-domain}/api/ucp/mcp. • Include a meta object carrying ucp-agent.profile in every request, and a meta["idempotency-key"] (UUID) for cancel_cart. • Note that update_cart uses PUT semantics: each request replaces the cart's full state, so send the complete line_items array on every update rather than patching individual fields. • Consult the updated request and response schemas for all cart tools and update your app to match. See the documentation for Cart MCP (https://shopify.dev/docs/agents/carts-and-checkout/cart-mcp) for more details.
Starting with GraphQL Admin API version 2026-10, the deprecated priceRule field on the DraftOrderDiscountNotAppliedWarning object is removed. This is a breaking change for apps that query priceRule on DraftOrderDiscountNotAppliedWarning, which is returned in draft order discount warnings from mutations such as draftOrderCalculate, draftOrderCreate, and draftOrderUpdate. If your app selects priceRule in these responses, you must update those queries before upgrading to 2026-10. The warning already exposes the relevant discount data directly, so you no longer need the legacy priceRule object. Use the following fields instead: • discountTitle — the title of the discount that couldn’t be applied. Use this instead of priceRule { title }. • discountCode — the code of the discount that couldn’t be applied. Use this instead of priceRule { discountCodes { nodes { code } } }. Update any query that reads priceRule from this warning to select discountTitle and discountCode instead. Before: ... on DraftOrderDiscountNotAppliedWarning { priceRule { title discountCodes(first: 1) { nodes { code } } } } After: ... on DraftOrderDiscountNotAppliedWarning { discountTitle discountCode } DraftOrderDiscountNotAppliedWarning was the only place where the legacy PriceRule object was reachable from the public GraphQL Admin API. As a result, removing priceRule also removes the PriceRule object and its related types from the public schema in 2026-10 and later. Older supported API versions continue to expose priceRule on DraftOrderDiscountNotAppliedWarning until those versions reach end of life. Learn more about the DraftOrderDiscountNotAppliedWarning object.
The ITEM_NOT_STOCKED_AT_LOCATION error will be removed from InventoryAdjustQuantities, InventoryMoveQuantities, InventorySetOnHandQuantities, and InventorySetQuantitiesUserErrorCode as of API version 2026-10. Following the changes described here, inventory quantities can now be adjusted at any location. As a result, the condition that previously triggered ITEM_NOT_STOCKED_AT_LOCATION can no longer occur, and this error is no longer emitted. This update removes an obsolete error code. If your app currently handles ITEM_NOT_STOCKED_AT_LOCATION, you can safely remove any logic that depends on this specific error.
Your app's admin performance data is now available in the Dev Dashboard, alongside your existing monitoring tools. This change eliminates the need to switch between Partner Dashboard tabs to check web vitals. What's changed The admin performance dashboards have moved from the Partner Dashboard to the Dev Dashboard. You can now access daily and 28-day P75 rollups for three Core Web Vitals: • LCP (Largest Contentful Paint): Measures loading performance. • INP (Interaction to Next Paint): Assesses interactivity. • CLS (Cumulative Layout Shift): Evaluates visual stability. Note: FID (First Input Delay) has been retired. INP has replaced it as a Core Web Vital, and the dashboards reflect this update. Each metric provides a clear pass/fail status based on the thresholds used for the Built for Shopify evaluation. The data displayed is the same as that used by the App Store to assess your app's compliance, ensuring consistency. What you need to do No code changes are required. Your app's web vitals telemetry will continue to function as before. If you've bookmarked admin performance pages in the Partner Dashboard, those URLs will automatically redirect to the Dev Dashboard. Links on the app ‘Distribution’ page now point to the new location. Resources • Built for Shopify requirements • Core Web Vitals documentation
Nov 30UpdateReleased OpenAI Deno SDKNov 6UpdateReleased GPT-4 Turbo Preview, updated GPT-3.5 Turbo, GPT-4 Turbo with Vision, Assistants API, DALL·E 3 in the API, and text-to-speech API Deprecated the Chat Completions functions parameter in favor of tools Released OpenAI Python SDK V1.0