apiPulse.app

Shopify

Storefront and admin API updates

Shopify API Changelog Monitoring

Shopify teams ship against a platform that changes constantly across storefront, admin, checkout, and app surfaces. This page is built for Shopify API Changelog Monitoring so you can review updates in one place and decide quickly whether a change affects your storefronts, apps, or merchant workflows.

A practical Shopify API Changelog Monitoring workflow makes it easier to spot breaking changes, new requirements, and deprecations early. That means less reactive debugging, better sprint planning, and a clearer path for testing storefront, admin, and app behavior before merchants notice issues.

The benefit of Shopify API Changelog Monitoring is simple: your team gets a repeatable way to watch changes, evaluate risk, and act before small upstream updates turn into customer-facing bugs. Storefront and admin API updates

Shopify API down?

Shopify API down? Soon we will add direct API status monitoring alongside Shopify API Changelog Monitoring. For now, go to the official API status page on the Shopify website. In the future, we plan to detect when Shopify APIs may be down even before the public status page is updated.

Recent changes

Showing the last 10 changes from this feed.

05-30-2026

Bots and agents should identify themselves via Web Bot Auth

What's changing Shopify now applies stricter rate limits to bots and agents that access the Storefront API and Shopify-hosted online store pages. Bots and agents that don't sign their requests are subject to the strictest limits. To qualify for higher rate limits, operators should sign their requests with Web Bot Auth. For more details, see Storefront rate limits. What you should do If you operate a bot or agent accessing Shopify storefronts, sign your requests using Web Bot Auth. To get started, review the Web Bot Auth architecture and Cloudflare's implementation guide — for context only, you do not need to enroll with Cloudflare. Higher access tiers If you require higher rate limits than those provided to Web Bot Auth traffic, please contact us through this form. Shopify Merchants Shopify merchants who want to crawl their own stores can find ready-to-use Web Bot Auth signatures in the Shopify admin.

Source
05-30-2026

Storefront Catalog MCP now implements UCP

What’s changing The following UCP catalog tools in Storefront Catalog are now available: - `search_catalog`: Search a store's product catalog with filters, pagination, and buyer context - `lookup_catalog`: Batch lookup products or variants by identifier with inputs correlation - `get_product`: Retrieve full product details with interactive variant selection, availability signals, and more Tool calls can be placed against the https://{storedomain}/api/ucp/mcp endpoint. What you should do The previous search and lookup tools are deprecated in favor of the above tool names and endpoint, as well as related updates to their request and response shapes to match UCP. The old versions will be maintained until June 15th, 2026, but all documentation will refer to the latest version. If you’re building with Storefront MCP tools: Update tool names to one of the supported tools above. Update endpoints to use https://{storedomain}/api/ucp/mcp. Consult the update request and response schemas for all tool calls and update your app to match. See the documentation for Storefront Catalog MCP for more details.

Source
05-29-2026

Customize /llms.txt, /llms-full.txt and /agents.md

Your store includes a default agents.md file accessible at /agents.md. The paths /llms.txt and /llms-full.txt also point to this content by default. Add any of the following templates under Online Store > Themes > Edit code to serve different content per path: templates/agents.md.liquid — controls /agents.md (and the default for the other two paths) templates/llms.txt.liquid — controls /llms.txt only templates/llms-full.txt.liquid — controls /llms-full.txt only If no template is present for a given path, it falls back to your agents.md template, then to the Shopify-generated default.

Source
05-29-2026

Function run log details are now automatically visible with the right access scopes

You no longer need to ask merchants to share function run logs with you. These logs are now automatically available in the Dev Dashboard for any function your app has the necessary access scopes to view. What's Changed Function run logs in the Dev Dashboard are now accessible based on the access scopes granted to your app by the merchant. The required scopes to view a log are determined by the function's input query. If your app has the necessary scopes to read these fields via the GraphQL Admin API, you will automatically see the run details without needing any additional action from the merchant. What You Need to Do If you expect to see function run details but don't, ensure your app has the scopes required by the input query. Here's how you can check: Request the scopes during your app's installation/authentication process: This is ideal for scopes your app consistently needs. Refer to Access scopes for instructions on declaring and requesting access scopes. Request protected customer data scopes when accessing customer data: Some fields, like customer details and addresses, require additional protected customer data access. Consult Protected customer data for the approval process and necessary data-level scopes. Use optional scopes for temporary or debugging access: If a scope is needed occasionally, such as for debugging, request it as an optional scope. Merchants can grant or revoke it without reinstalling the app. Once the required scopes are granted, the run details will automatically be visible the next time you access the log.

Source
05-22-2026

Headless checkout SSO is now documented with sso=silent

We’ve updated our headless checkout authentication docs to refer to the silent single sign-on query parameter as sso=silent instead of logged_in=true. This is a terminology and documentation update only. Existing checkout URLs that use logged_in=true will continue to work. Going forward, Shopify docs and examples will use sso=silent when describing the silent SSO flow from a headless storefront to checkout. Use sso=silent when you want checkout to verify the buyer’s active session on the customer accounts domain through an OIDC-compliant flow. For most headless storefronts using the Customer Account API, we continue to recommend continuous cart authentication by setting the cart’s customerAccessToken and redirecting buyers to the cart’s checkoutUrl. Learn more about authenticating buyers in checkout.

Source
05-22-2026

Next Generation Events now available in developer preview

Next Generation Events are now available in developer preview, with field-level control over when events fire, what data they carry, and what triggered each delivery. Subscribe to exactly what you care about. Field-level triggers pre-qualify deliveries before they reach your endpoint. A subscription scoped to product.variants.price won't fire on title edits, tag updates, or status changes. Only when the price changes. Get the payload your app needs, not a fixed schema. You define the delivery payload with a standard Admin GraphQL query. No over-fetching fields you'll discard. No extra API call to get the data you actually wanted after the webhook lands. Know what fired for each delivery. Every delivery includes fields_changed: an explicit list of the fields that triggered the event, with full entity paths and IDs. That means you don't need to infer, or diff against prior state. Filter on current state. query_filter narrows deliveries based on the current state of your query output. Use it to skip events that don't meet your conditions, like only delivering for active products. Configure in code. Subscriptions live in shopify.app.toml alongside your other app configuration. Version-controlled, reviewable, and deployable. As a developer preview, Events are available in the unstable API version and APIs may change. Product and Customer topics are live today. Configuration and payload [events] api_version = "unstable" [[events.subscription]] handle = "price_sync" topic = "Product" actions = ["update"] triggers = ["product.variants.price", "product.variants.compareAtPrice"] uri = "/api/events" query = """ query priceSync($productId: ID!, $variantsId: ID!) { productVariant(id: $variantsId) { id price compareAtPrice sku } product(id: $productId) { id title status } } """ query_filter = "product.status:'ACTIVE'" Every delivery includes fields_changed, data from your query, and query_variables used to fetch it: { "topic": "Product", "action": "update", "handle": "price_sync", "data": { "productVariant": { "id": "gid://shopify/ProductVariant/456", "price": "24.99", "compareAtPrice": "34.99", "sku": "SIGNAL-NOT-NOISE" }, "product": { "id": "gid://shopify/Product/123", "title": "Peace & Quiet Tee", "status": "ACTIVE" } }, "fields_changed": [ "product[id: 'gid://shopify/Product/123'].variants[id: 'gid://shopify/ProductVariant/456'].price" ], "query_variables": { "productId": "gid://shopify/Product/123", "variantsId": "gid://shopify/ProductVariant/456" } } Learn more Learn more about how Events relate to Webhooks: https://shopify.dev/docs/apps/build/events-webhooks Get started by Creating an Events subscription.

Source
05-21-2026

Shopify CLI 4.0: SemVer, auto-updates, removing deprecated flags and commands

The release of Shopify CLI 4.0 today brings clarity to CLI versioning, the introduction of automatic updates, and the announced removal of the deprecated --force flag from shopify app deploy. Semantic Versioning Shopify CLI is now following semantic versioning practices. Releases with new features will be minor versions, and bug fixes will be patch versions. When required, major version releases will be used to communicate breaking changes to CLI command structure or behavior. For more information, see our announcement of the move to SemVer. Automatic Upgrades Starting with Shopify CLI 4.0, Shopify CLI upgrades itself automatically using the package manager you installed it with. Auto-upgrade is skipped in CI, project-local installs, and for major version releases. Automatic upgrades can be disabled with the shopify config autoupgrade off command. For more information, see Shopify CLI documentation. Removal of the --force flag for app releases The --force flag on the app deploy and app release commands didn’t distinguish between low-risk operations (adding or updating extensions) and high-risk ones (deleting them). This flag has been removed in Shopify CLI 4.0. The previously released --allow-updates and --allow-deletes flags give you granular control, so your CI/CD pipelines can run unattended without the risk of accidental, irreversible deletions. For more information, see the March 2026 changelog. Other removed commands and flags The following deprecated commands and flags have also been removed in Shopify CLI 4.0: shopify webhook trigger (use shopify app webhook trigger) shopify theme serve (use shopify theme dev) shopify app generate schema (use shopify app function schema) shopify app webhook trigger --shared-secret (use --client-secret) shopify app generate extension --type (use --template)

Source
05-21-2026

Build App Home as a UI extension

You can now create your app's landing page in App Home as a Preact-based admin UI extension using the new admin.app.home.render target. This means your App Home UI extensions are bundled with your other admin UI extensions, eliminating the need for a separate web server to render your app's primary workspace. Use this extension type when you want: A persistent, full-page app workspace that's integrated into your extension bundle, rather than a separate iframe-hosted web app. A unified source of truth for your app's primary UI, alongside your other admin UI extensions. The performance and design-system advantages of Polaris web components without the need for hosting a web server for the App Home experience. Availability App Home UI extensions are available starting from API version 2026-07 and are intended for custom-distribution apps. If you're developing a public app for the Shopify App Store, you should continue using the iframe-based App Home solution. Get started To begin, scaffold a new extension-only app by selecting Build an extension-only app when prompted: shopify app init Alternatively, add an App Home UI extension to an existing app by selecting App home when prompted: shopify app generate extension For a comprehensive list of target APIs, web components, and configuration options, refer to the App Home UI extension reference.

Source
05-20-2026

Shop Minis March April 2026 update

New Features Optional Consent Users can now reject scopes and continue using your Mini. Consent is no longer all-or-nothing — if a user declines a scope, your Mini should gracefully degrade rather than block the experience. If your Mini hard-fails when a scope is rejected, please update it using the new hooks below. useCheckScopesConsent Hook Check at runtime which scopes a user has granted. Use this to conditionally render features that depend on a particular scope. Usage: import {useCheckScopesConsent} from '@shopify/shop-minis-react' function MyMini() { const {scopes} = useCheckScopesConsent() if (scopes.includes('product_lists:write')) { return } return } useRequestScopesConsent Hook Re-request consent after a user has previously declined. The hook must be invoked from a user interaction — you cannot re-prompt automatically. Use this for flows where granting consent unlocks a clear, user-initiated action. Usage: import {useRequestScopesConsent} from '@shopify/shop-minis-react' function GrantAccessButton() { const {requestScopesConsent} = useRequestScopesConsent() return ( requestScopesConsent(['product_lists:write'])}> Enable saving products ) } useCheckPermissions Hook Separate from scopes, useCheckPermissions lets your Mini check OS-level permissions (camera, photo library, and so on) before invoking an action that requires them. Usage: import {useCheckPermissions} from '@shopify/shop-minis-react' function CameraFeature() { const {permissions} = useCheckPermissions(['camera']) if (permissions.camera === 'granted') { return } return } request_blocked Sentinel When a user has declined a scope or permission and the platform will not re-prompt, the relevant hooks now return a request_blocked sentinel value instead of null. This lets you distinguish "not asked yet" from "asked and blocked" and tailor your UI accordingly. See the Scopes Consent docs on shopify.dev for the full state machine. Intents Intents are a new communication layer between the Shop app and Shop Minis. The Shop app launches your Mini from contextually relevant moments — such as a product detail page — and passes along the context (typically a product). For partners, this opens a new path to distribution: instead of relying on the Explore tab alone, your Mini can be surfaced where buyer intent is highest. Two intents are supported today: | Intent | What it's for | | :

Source
05-15-2026

Shipping line field now available on FulfillmentOrderLineItem

You can query the shippingLine field on FulfillmentOrderLineItem. This field returns the ShippingLine associated with a fulfillment order line item, if available. This feature simplifies the process for order management and fulfillment apps to identify the shipping method for each line item. It is particularly useful in scenarios where fulfillment orders are merged across different delivery profiles, and the original per-line shipping service is not identified by the fulfillment order's delivery method. For example, apps can use properties such as shippingLine.code, shippingLine.title, and shippingLine.source to accurately map line items to the correct carrier service or shipping method. For more information, refer to the FulfillmentOrderLineItem reference.

Source