Shopify Developers Release Notes

The Shopify Dev MCP server now includes support for code generation for POS (Point of Sale) UI extensions.

With this update, you can use the Shopify Dev MCP as a virtual pair programmer within your preferred IDE. This enhancement allows you to:

• Generate code snippets efficiently
• Explore API capabilities seamlessly
• Accelerate your development process across the Shopify platform

Get Started

If you're already using the Shopify Dev MCP server, support for POS UI extensions is automatically included in the latest version. If not, follow these steps to get started:

• Configure the Shopify Dev MCP server to integrate it with your development environment.
• Unlock the new capabilities by ensuring your setup is up-to-date.

By following these steps, you can take full advantage of the new features and enhance your development workflow.

Original source Report a problem

What's changed

This change affects two key integration points:

Tax calculation requests

• Customer, Company, Company Location, Product, and Product Variant IDs now use the GID format.

Tax summary webhooks

• All entity IDs within the summary section (Order, Customer, Product, Product Variant, Sales Agreement, Sale, Line Item, Company, Company Location, Shipping Line, and Tax Line) now use the GID format.
• The webhook payload also includes new admin_graphql_api_id fields at the top level for Tax Summary, Shop, and Order entities.

Changes include:

• Top Level: Adds shop_admin_graphql_api_id and order_admin_graphql_api_id fields (existing shop_id and order_id remain as integers).
• Customer IDs: Changes from "id": "5" to "id": "gid://shopify/Customer/5".
• Product IDs: Changes from "id": "1" to "id": "gid://shopify/Product/1".
• Product Variant IDs: Changes from "id": "1" to "id": "gid://shopify/ProductVariant/1".
• Line Item IDs: Changes from "line_item_id": "5" to "line_item_id": "gid://shopify/LineItem/5".
• Sale IDs: Changes from "id": "9" to "id": "gid://shopify/Sale/9".
• Agreement IDs: Changes from "id": "6" to "id": "gid://shopify/Agreement/6".
• Company IDs: Changes from "id": "3" to "id": "gid://shopify/Company/3".
• Company Location IDs: Changes from "id": "4" to "id": "gid://shopify/CompanyLocation/4".
• Shipping Line IDs: Changes from "id": "4" to "id": "gid://shopify/ShippingLine/4".
• Tax Line IDs: Changes from "id": 6 to "id": "gid://shopify/TaxLine/6".

What you need to do

Update your integrations to handle the GID format when processing tax calculations and webhook payloads in API version 2026-01 and later. The following are some examples:

Tax calculation request

Before (2025-10 and earlier):

{
  "cart": {
    "buyer_identity": {
      "customer": {
        "id": "593934299"
      }
    }
  }
}

After (2026-01):

{
  "cart": {
    "buyer_identity": {
      "customer": {
        "id": "gid://shopify/Customer/593934299"
      }
    }
  }
}

Tax summary webhook

Before (2025-10 and earlier):

{
  "id": 80,
  "shop_id": 1,
  "order_id": 64,
  "summary": {
    "agreements": [{
      "id": "82",
      "sales": [{
        "id": "106",
        "line_item_id": "76"
      }]
    }]
  }
}

After (2026-01):

{
  "id": 80,
  "admin_graphql_api_id": "gid://shopify/TaxSummary/80",
  "shop_id": 1,
  "shop_admin_graphql_api_id": "gid://shopify/Shop/1",
  "order_id": 64,
  "order_admin_graphql_api_id": "gid://shopify/Order/64",
  "summary": {
    "agreements": [{
      "id": "gid://shopify/SalesAgreement/82",
      "sales": [{
        "id": "gid://shopify/Sale/106",
        "line_item_id": "gid://shopify/LineItem/76"
      }]
    }]
  }
}

Original source Report a problem

What’s changing

We will be enforcing Shopify's protected customer data policy for all web pixel extensions starting on December 10th, 2025. Customer personally identifiable information (PII)—including name, email, phone, and address fields—will only be present in web pixel payloads when the app has been approved for the corresponding protected scopes.

• Web pixel payloads will be filtered at runtime based on the app’s approved access scopes.
• If your app is not approved for a given scope, the corresponding fields in the pixel event will be set to null. Event data structure remains stable.
• Enforcement applies on all web pixel surfaces: storefront, checkout, and customer accounts.
• Custom pixels are out of scope for this change.

Protected scopes enforced

• read_customer_name
• read_customer_email
• read_customer_phone
• read_customer_address
• read_customer_personal_data

Example

{
  "event": "checkout_completed",
  "customer": {
    "email": null,           // null if not approved for read_customer_email
    "first_name": null,      // null if not approved for read_customer_name
    "phone": null            // null if not approved for read_customer_phone
  },
  "shipping_address": {
     "first_name": null,	// null if not approved for read_customer_name
     "address_1": null, 	// null if not approved for read_customer_address
     "address_2": null, 	// null if not approved for read_customer_address
     "zip": null,       	// null if not approved for read_customer_address
     "phone": null            // null if not approved for read_customer_phone
     [other address fields exempt]
  }
}

Non-PII data events will continue to fire normally. Your analytics, conversion tracking, and non-PII use cases will not be affected.

What you need to do

• Review and request access. Ensure you have approval for the protected scopes you require. See Protected Customer Data Policy. You should only request the scopes your app uses.
• Update your code paths. Handle null for gated fields without breaking event handling or analytics pipelines.
• Test across surfaces. Verify behavior on storefront, checkout, and customer accounts. No downtime is expected.

This change will take effect starting on December 10th, 2025. We recommend submitting your request for protected customer data review as soon as possible if you need to maintain access to these values.

No action is needed if your app is already approved for protected customer data, or is resilient to null values. If you have questions about this change, please comment on this post in the Developer Community forums.

Original source Report a problem

What's New

The taxSummaryCreate mutation enables apps to request the generation of tax summaries for orders. The tax_summaries/create webhook is triggered by events that may affect tax liability, such as fulfillments and refunds.

Using the Mutation

The mutation accepts either a specific order ID or a time range for bulk processing:

mutation {
  taxSummaryCreate(orderId: "gid://shopify/Order/123456789") {
    enqueuedOrders {
      id
    }
    userErrors {
      field
      message
    }
  }
}

Webhook Payload

The tax_summaries/create webhook provides comprehensive tax data, including:

• Sales agreements and associated sales details
• Delivery groups with fulfillment information
• Tax exemption details
• Return sales types for refund workflows
• Order context and financial status

Requirements

• Access Scope: write_taxes
• Tax Platform Access: Tax Platform features

Learn More

For information about the Tax Platform and partnership opportunities, see Building tax apps.

Original source Report a problem

Carrier Service API callback payload update

The Carrier Service API callback payload has been enhanced to include order totals and customer tags. This update allows you to calculate shipping rates more effectively by considering the order value and customer segments.

New Payload Fields

• order_totals
  • subtotal_price: The total price of items before discounts and taxes.
  • total_price: The final price after applying discounts and taxes.
  • discount_amount: The total amount of discounts applied to the order.
• customer
  • id: The unique identifier for the customer.
  • tags: Labels associated with the customer, useful for segmentation.

These new fields are automatically included in all callback responses, enabling you to tailor shipping rates based on detailed order and customer information. For more information on how to implement these changes, please refer to the Carrier Service API documentation.

Consider updating your shipping rate calculations to leverage these new fields for a more customized shipping experience.

Original source Report a problem

Admin API 2026-01 Update

As of Admin API 2026-01, the phone field is now publicly available in the orderUpdate mutation's OrderInput. This field allows developers to update the customer phone number for an order, overwriting the existing phone number.

This change brings parity with the REST API, which already supports updating the phone field through the Order resource. The phone field is particularly useful for maintaining accurate customer contact information, especially for SMS notifications and order-related communications.

Implementation details

For implementation details, refer to the orderUpdate mutation documentation.

Original source Report a problem

What's Changed

Here's an overview of the updates:

New Bulk Operations Retrieval Queries

We have added two new queries for accessing your bulk operations:

• bulkOperations: A connection-based query that returns a paginated list of all your bulk operations, complete with filtering and sorting options.
• bulkOperation: A single-object query that retrieves a specific bulk operation by its ID.

Enhanced Filtering and Search Capabilities

The bulkOperations connection now supports flexible querying with the following features:

• Status Filtering: Locate operations by status (e.g., canceled, completed, running).
• Type Filtering: Filter operations by type (query or mutation).
• Date Filtering: Search for operations created before or after a specific date.
• Sorting Options: Sort operations by created_at, completed_at, or status in ascending or descending order.
• Search Syntax: Use field:value patterns for precise filtering.

What You Need to Do

Depending on your requirements, follow these steps:

To List and Filter Bulk Operations

Utilize the bulkOperations connection query with search syntax:

query {
  bulkOperations(
    first: 10
    query: "status:completed operation_type:query created_at:>2025-10-10"
    sortKey: CREATED_AT
    reverse: true
  ) {
    edges {
      node {
        id
        status
        query
        createdAt
        completedAt
        url
      }
    }
    pageInfo {
      hasNextPage
      hasPreviousPage
    }
  }
}

To Retrieve a Specific Bulk Operation

Use the bulkOperation query:

query {
  bulkOperation(id: "gid://shopify/BulkOperation/123456789") {
    id
    status
    query
    createdAt
    completedAt
    url
    errorCode
  }
}

If You're Using Existing Bulk Operation Workflows

No changes are necessary. The current Bulk Operation can still be used but is being deprecated.

Why We Made This Change

Previously, you could only access the most recent bulk operation through current Bulk Operation. These new queries offer:

• Complete visibility into all your bulk operations, not just the current one.
• Enhanced debugging capabilities by filtering operations by status or date.
• Efficient pagination for managing large numbers of operations.
• Simplified monitoring, debugging, and management of bulk operations at scale.

Learn More

• Bulk Operations Queries Guide

Original source Report a problem

We now support enabling and referencing standard metafield and metaobject definitions through an app’s TOML file. Key benefits include:

• Standard metafield and metaobject definitions can be enabled through TOML, and managed through the app dev or app deploy command.
• Shopify automatically distributes these definitions to multiple shops simultaneously, significantly speeding up migration processes.
• Updates are atomic, ensuring that all stores consistently maintain the same version of your definitions.

For more information, see the custom data documentation on shopify.dev.

Original source Report a problem

What's new

• Homepage spotlight: BFS now appears in the featured header section of the App Store homepage, giving certified apps maximum exposure to browsing merchants.
• Priority recommendations: BFS apps receive preferential positioning on some category pages.
• Interactive BFS badge: All BFS badges across the App Store are now clickable to provide merchant education on BFS standards.

These enhancements work alongside existing Built for Shopify benefits including ranking boosts and the BFS search filter, making Built for Shopify the most effective way to maximize your app’s visibility and discovery potential in the App Store.

Original source Report a problem