Shopify Developers Release Notes

In the API 2026-04 release candidate version, you can now include a new field called paymentProcessingPolicy when creating a billing attempt using the subscription Billing Attempt Create mutation. A billing attempt is an action to charge a customer based on their subscription.

The paymentProcessingPolicy field determines how the billing attempt is handled depending on the validity of the payment method:

• If you don't provide the paymentProcessingPolicy field, or if you set it to FAIL_UNLESS_VALID_PAYMENT_METHOD, a valid payment method is necessary to create an order successfully.
• Alternatively, if you set the value to SKIP_PAYMENT_AND_CREATE_UNPAID_ORDER, the system will create an unpaid order even if there isn't a valid payment method available on the subscription contract.

For detailed implementation instructions, please refer to our documentation on building a subscription contract.

Original source Report a problem

As of API Version 2026-04 third-party logistics providers (3PLs) and fulfillment apps can now report progress on fulfillment orders with the fulfillmentOrderReportProgress mutation. This feature enables fulfillment services to indicate that work has commenced and, optionally, add brief status notes so merchants see what’s happening in their fulfilment pipeline.

Key Details

• Reporting progress for 3PL-managed orders works with fulfillment orders in IN_PROGRESS status
• Reporting progress for merchant-managed orders works with fulfillment orders in OPEN or IN_PROGRESS status (requires write_merchant_managed_fulfillment_orders scope)
• Supports optional reasonNotes field (up to 256 characters) for additional context
• New fulfillment_orders/progress_reported webhook available to track when progress has been reported
• fulfillmentOrder.supportedActions field will now return the REPORT_PROGRESS action when a fulfillment order can have progress reported.

New Webhooks

Topic: fulfillment_orders/progress_reported

This webhook is triggered when progress is reported on a fulfillment order. The payload includes the fulfillment order ID and status, the initial_status before the update, and progress_report details including reason_notes and attribution data for the app or user that reported the progress.

Topic: fulfillment_orders/manually_reported_progress_stopped

This webhook fires when a merchant-managed fulfillment order that has had progress manually reported (via fulfillmentOrderReportProgress) is subsequently marked as "ready for fulfillment", transitioning it from IN_PROGRESS back to OPEN status. This webhook allows apps to know when a merchant has "undone" or "cancelled" the in-progress status they previously reported.

Original source Report a problem

As of API version 2026-07, the payment method identifier field is now required when using the customerPaymentMethodRemoteCreate mutation with Stripe, Authorize.net, or Braintree inputs.

The affected fields are:

• paymentMethodId on RemoteStripePaymentMethodInput
• customerPaymentProfileId on RemoteAuthorizeNetCustomerPaymentProfileInput
• paymentMethodToken on RemoteBraintreePaymentMethodInput

These fields were previously optional at the schema level but are required for the payment method to be functional. Without a payment method identifier, remotely created payment methods cannot be used for payment processing. This change aligns the API schema with existing runtime requirements.

If you are already passing a payment method identifier when calling this mutation, no changes are needed. If you are not, update your integration to include the appropriate identifier for your gateway before adopting API version 2026-07.

Original source Report a problem

Sales channel apps can now create and manage multiple channel connections from a single app. A single app can now establish more than one channel on a shop, with a separate specification and/or external account for each connection.

Why this matters

If you build a sales channel app that needs separate connections for different accounts or to sell in different markets or have different surfaces, you no longer need to split that model across multiple apps. You can keep those connections inside one app and manage them as distinct channels.

What's new

• A single sales channel app can establish multiple channels on the same shop.
• Sales channels can now uses the Channel Config extension plus one specification file per target channel.
• Each channel can point to a different specification and external account.

What partners should do

For new sales channel apps

• All new sales channels should add a Channel Config extension.
• Define one specification file per target channel.
• Use channelCreate with a specificationHandle, accountId, and accountName to create each channel connection.

For existing sales channel apps

• Migrate legacy sales channel app to use channel connections using this guide
• Review any downstream code that assumes one channel per app. If your app reads or mutates channel-specific state, pass a channel ID instead of relying on app-level defaults.

New APIs in this release

• channel
• channelCreate
• channelByHandle
• channelUpdate
• channelDelete
• channelFullSync

APIs impacted by this release

Deprecated: These single-channel APIs are now deprecated. They still function today but will be removed in a future API version:

Deprecated API Use instead publishable Publish To Current Channel publishable Publish publishable Unpublish To Current Channel publishable Unpublish App Installation.channel Root-level channels query App Installation.publication Root-level publications query Product.published On Current Publication published On Publication Publishable.resource Publication On Current Publication resource Publications

Updated: These APIs now accept an optional channelId input to specify which channel the operation applies to. If your app creates multiple channels, you must pass channelId. If your app has a single channel, existing calls continue to work without changes:

• bulk Product Resource Feedback Create
• bulk Product Publication Status Update

Original source Report a problem

As of API version 2026-04, you can validate billing addresses and purchase order (PO) numbers in Cart and Checkout Validation Functions. We've added billing address and PO Number to the function input graph and introduced new checkout field targets. This allows you to enforce compliance rules such as blocking prohibited billing countries and requiring PO numbers for B2B orders without relying upon client-side UI extensions.

What's changed

• Input graph fields: billingAddress and poNumber are available on all Shopify Function input graphs. They return null outside of Cart and Checkout Validation.
• Supported checkout field targets for error messages in Cart and Checkout Validation:
  • $.cart.billingAddress.{field} (all standard address subfields)
  • $.cart.poNumber

Impact

• No breaking changes. Your existing functions continue to run. You can optionally add validations for these targets.
• Checkout surfaces field-level errors for billing address and PO number when your function returns validations for these targets.

To learn more, see the developer documentation.

Original source Report a problem

The Metafield type now includes a translations field, enabling you to query localized metafield values directly via the GraphQL Admin API. This enhancement allows you to access translations for metafields associated with any resource, including products, collections, customers, orders, locations, and more.

Querying translations

To query translations for a resource's metafields, including their localized values, see the Get translations for a product metafield example.

Registering a translation

To register a translation, use the translationsRegister mutation with the metafield's resource ID and a content digest. The compareDigest ensures that translations remain synchronized with the original value. You can obtain this digest when creating or querying a metafield.

See the Register a French translation for a metafield value example for the full workflow.

Translation is supported for text-based metafield types, including single_line_text_field, multi_line_text_field, rich_text_field, and html. Ensure that the target locale is enabled and published on your store.

For further information, refer to the Metafield and translationsRegister documentation.

Original source Report a problem

As of GraphQL API version 2026-04, all Shopify Functions can access app-owned metaobject entries.

Metaobjects are now available for every function target. This feature enables you to query additional structured data present in metaobjects, such as tiered pricing and bundles. To query a metaobject entry, specify a handle or ID in your input query file. Note that only app-owned metaobject types, identified by the $app reserved prefix, are accessible to functions.

For details look under the Shop field for any of the 2026-04 Functions, like the metaobject input object in Cart Transform. Learn more about metaobject ownership.

Original source Report a problem

As of Customer Account API version 2026-04, the Draft Order Line Item object includes a new components field. This field returns the individual component line items associated with a parent line item.

Additionally, a new optional argument, flatten Components, has been introduced to the Draft Order.line Items connection. For API versions 2026-04 and later, flatten Components defaults to false, meaning only top-level line items are returned as nodes, with their components accessible via the Draft Order Line Item.components field. If set to true, both parent and component line items are returned as top-level nodes, aligning with the behavior of earlier API versions. For versions prior to 2026-04, flatten Components defaults to true to ensure backward compatibility.

Example

query {
  draftOrder(id: "gid://shopify/DraftOrder/1") {
    lineItems(first: 10) {
      nodes {
        name
        quantity
        components {
          name
          quantity
        }
      }
    }
  }
}

Original source Report a problem