Shopify API 2026-10 RC migration checklist: subscriptions, orders, inventory and Checkout

Define the stage: RC is for development and testing until stable on October 1

At the September 22, 2026 check, Shopify’s 2026-10 release notes listed changes to orders, Metafields, Customer Account, taxes and shipping, marking the version Release Candidate. The page explicitly says it is for development and testing before October 1 and becomes stable afterward. The task now is compatibility validation, not describing every production store as already switched.

Individual changes have their own original announcement dates: priceRule on June 23, Carrier Service on June 26, Customer Account Checkout on July 6, Metafield filters on July 24 and order-address taxes on July 30. Do not treat dates displayed on the aggregate timeline as the RC launch date or the first announcement of every feature. Use the corresponding changelog for each date.

Order addresses and taxes: reread financial fields after a successful update

From API 2026-10, changing the shipping address of a completely unfulfilled order through orderUpdate or REST Admin order update recalculates taxes for the new destination. Apps should then reread taxLines, totalTaxSet, order totals and balances instead of retaining pre-update caches. Paid orders may have additional amounts due or refundable differences, which must follow the merchant’s own tolerance and financial procedures.

Keep three boundaries explicit: requests before 2026-10 change the address without recalculating tax; partially or fully fulfilled orders are not recalculated; and non-editable orders are not recalculated. A verifiable test creates a completely unfulfilled order in a development store, records taxes and balance, changes the address across tax regions and compares fields, then checks partially fulfilled fixtures for unintended recalculation. This is a test design, not an observed customer incident.

Subscription contracts: move from stateful Draft to calculate, poll, review and commit

SubscriptionContractCalculation succeeds SubscriptionDraft, but both coexist during the RC. Apps creating, updating or editing subscription contracts should use subscriptionContractCreateCalculate, subscriptionContractUpdateCalculate or subscriptionBillingCycleContractEditCalculate as appropriate. Apps that only read contracts or use status mutations such as subscriptionContractActivate and subscriptionContractPause need not rewrite for this change. “Successor” does not mean the old API disappears immediately in 2026-10.

When calculate returns SubscriptionContractCalculationPending, poll subscriptionContractCalculation or subscribe to subscription_contract_calculations/succeed and subscription_contract_calculations/fail. On success, review the calculated contract, totals, warnings and errors before calling subscriptionContractCalculationCommit; a webhook does not commit automatically. If input validation directly returns a user error, correct the input first because no asynchronous calculation is created. Failed calculations have errors; failures voided by Shopify may have none, and official documentation recommends retrying.

Test at least three paths: a successful calculation committed after human or rules-based review; input user errors that never enter polling; and fail/voided results that stop or retry within limits depending on whether errors exist. Commit creates a new contract version but does not change existing orders or fulfillments. Stop the upgrade and retain the old-version path if polling times out, differences are unexplained, webhook and query states disagree or old and new billing amounts cannot be reconciled.

Schema enumeration: error codes, fulfillment enums, exchange fields and Metafields

InventoryAdjustQuantities, InventoryMoveQuantities, InventorySetOnHandQuantities and InventorySetQuantitiesUserErrorCode remove ITEM_NOT_STOCKED_AT_LOCATION. Remove or rewrite dependent error mappings, alerts, fixtures and generated enums. OrderDisplayFulfillmentStatus fields such as Order.displayFulfillmentStatus gain FULFILLMENT_NOT_REQUIRED, replacing UNFULFILLED when remaining fulfillable quantity is 0. Add tests for the new value in exhaustive switches, report mappings and frontend labels.

ExchangeLineItem adds productId, title, variantSku and variantTitle. Request these only if the app needs product identity or display snapshots for exchange lines. Update queries, generated types, permission review and null fixtures first, then verify old clients do not fail on response selection sets or local schema snapshots.

DraftOrderDiscountNotAppliedWarning returned by draftOrderCalculate, draftOrderCreate and draftOrderUpdate no longer provides priceRule. Read discountTitle and discountCode instead. Because this was the last reachable PriceRule entry in the public schema, related legacy types are also removed. Search query text, fragments, generated types, schema snapshots, mocks and fixtures together.

Metafield filters now return errors directly when a definition is missing, filtering is disabled, or field types or comparison operations are unsupported, rather than silently ignoring predicates. Verify each definition, filtering configuration and comparison during migration, and create valid, invalid and empty-result query fixtures. Do not swallow GraphQL errors and return an empty list, disguising configuration failure as no data.

Customer Account and tax payloads: more than renaming fields

The Customer Account API removes Customer.lastIncompleteCheckout and unreachable subtrees including Checkout, AppliedGiftCard, AvailableShippingRates, CheckoutLineItem and ShippingRate. Official guidance explicitly says there is no Customer Account API replacement. Remove references from dependent apps. If the product needs active shopping state, assess the Storefront cart flow separately rather than inventing a one-to-one replacement field.

Third-party tax integrations also need to check tax calculation requests and tax summary webhooks. Entity references become gid://shopify/... values, with top-level fields such as admin_graphql_api_id added. Validate ID parsing, persistence keys, webhook fixtures, replay tools and log sanitization together. Changing integers to strings in type definitions alone is not completion.

Carrier Service: registration success does not establish checkout rates

In 2026-10, carrierServiceCreate and the corresponding REST create endpoint only register the service; rates are no longer automatically added to the General shipping profile. After successful creation, the app or merchant must configure carrier-calculated rates in applicable shipping profiles and zones, then verify checkout visibility with representative addresses.

Migration tests should distinguish four layers: service-object existence, profile association, correct zone coverage and actual checkout rates. A successful create response is not complete launch validation. Do not extend official statements about create into a guarantee of identical behavior for every update operation.

An actionable migration sequence

First, inventory code and configuration dependencies: subscription-contract editing, inventory error codes, fulfillment enums, exchange lines, order-address updates, DraftOrder warnings, Metafield filters, Customer Account Checkout, tax payloads and Carrier Service. Second, regenerate types against the 2026-10 schema so removed fields and new enums surface during compilation or tests. Third, prepare fixtures for calculation success/failure, inventory errors, zero remaining fulfillment, null exchange fields, tax-region changes, invalid filters, GID payloads and shipping profiles.

Fourth, compare old-version and 2026-10 requests, asynchronous states, responses, errors, balances and checkout results in development stores or isolated environments. Fifth, record the responsible layer, stop condition and fallback version for each failure. Customer.createdAt, ShopifyQL app analytics and Storefront @inContext(channelId) are separate RC additions, not mandatory parts of subscription, order or inventory migration. Evaluate them only if actually used.

Validation, stop and fallback boundaries

Minimum acceptance includes generated types free of removed references; distinct successful, failed and voided subscription-calculation paths without erroneous commits; complete new error-code and fulfillment-enum mappings; null fixtures for new ExchangeLineItem fields; explained order-tax and balance differences; explicit invalid-Metafield-filter errors; no requests for removed Customer Account subtrees; parseable tax GIDs; and verifiable Carrier Service profiles, zones and checkout rates.

Stop the version upgrade for long-pending calculations, uncertain fail/voided handling, unexplained pre-commit or financial differences, lost webhook entities, missing expected checkout rates, or rollback that would damage migrated data. During RC, a still-supported, validated old version can provide repair time, but is not a permanent solution. If Shopify changes the RC before October 1, recheck the original URL and update this same page.