Shopify Editions 2026: A Developer's Breakdown (Interview With Shopify's VP of Product)

Shopify Editions 2026 landed with a stack of updates aimed squarely at developers. To cut past the marketing and get to what actually changes for the people who build on Shopify, I sat down with Ethan, VP of Product at Shopify.

Ethan runs a team called Shopify Foundations, which owns the end-to-end developer experience: shopify.dev, the dev docs and community, the CLI for building apps, the dev dashboard, and app distribution through the App Store and partner directory. His team also owns the core primitives you build with (metafields, metaobjects, Shopify Functions, and the Polaris UI toolkit) plus Flow and analytics.

In other words, the right person to explain what shipped and why it matters. Here is the developer's breakdown.

Webhooks, rebuilt from scratch (next-gen Shopify events)

If you build apps, this is the update to understand first. Webhooks are Shopify's event system: instead of polling the API every few seconds asking "is there a new order yet?", you subscribe to an event and Shopify notifies you when it happens.

The problem with the old system: say you only care about price changes. You would subscribe to a product update webhook, and Shopify would send you a giant payload containing the entire product in its new state, sometimes 60, 80, or 100 fields. It was then on you to store a local copy of the previous version, diff it against the payload, and work out what actually changed. Most of that traffic you did not care about.

Next-gen Shopify events fix this with two big changes:

• Triggers. In your subscription you specify the exact field you care about. For example, trigger on variants.price and variants.compare_at_price. When the event fires, Shopify tells you specifically which of those changed, so you can be confident you are only notified about the thing you asked for.
• Custom payloads. By default the event is essentially payloadless. You hand Shopify a GraphQL query to run when the trigger fires, and Shopify pulls exactly the data you asked for. You define your own payload (say, just the product ID, title, and status).

As Ethan put it, this is the same shift the API itself went through moving from REST to GraphQL, now applied to webhooks: from rigid, one-size-fits-all responses to queries that return precisely what you need.

Availability: next-gen events are live today for the products and customers resources, and the plan is to extend them to all resources and fully replace the old webhook system over time.

An honest take on Sidekick

Sidekick is Shopify's AI assistant in the admin. Ethan uses it regularly on an internal test shop, and his read is that the capabilities have grown a lot. It started out answering basic questions about your store. Now you can ask it to build automations ("tag every customer who spends $5,000 or more as VIP" kicks off a Flow workflow) and ask analytical questions in plain English ("how many orders did I have in the last 30 days, and how many were over $5,000?").

The analytics use case is the standout. Questions that previously meant writing custom ShopifyQL or clicking through a report editor can now be asked in plain language. Ask "what's my best-performing marketing channel?" and you get the full breakdown back.

My own take: Sidekick is genuinely useful for documentation and for finding a setting in the admin. For theme and section work I still prefer a local development environment, my own AI of choice, and the fine-grained control of Git. Different jobs, different tools.

Building apps with Sidekick is front-end only (for now)

Sidekick can now generate apps, but with an important limit: there is no backend. Think front-end-only apps. It can build something like a form, but it cannot stand up a server or run third-party queries. Checkout UI extensions are also not generatable from Sidekick today, though that may come later.

Sidekick app extensions (now GA)

This is the piece most app developers should pay attention to. A typical merchant runs their business on a stack of apps: one for email, one for subscriptions, and so on. Until now, that app data was invisible to Sidekick. Sidekick app extensions close that gap, and they are now generally available on all shops.

There are two types:

Data extensions

A data extension lets Sidekick answer merchant questions using your app's data. Say a merchant asks, "how did my Spring Promo campaign go?" Sidekick works out that it should ask your email app, passes it the context, and your app responds with the numbers: sent to a million people, 200,000 opens, 100,000 clicks, and so on. That information then surfaces inside Sidekick seamlessly.

You build it with the same extension mechanism you would use for a checkout extension. You define a set of routes (a search campaigns route, a get campaign detail route, and so on) and describe in plain English what each one does. Shopify handles the orchestration of deciding which route to invoke. Developers who implemented it before GA reported it was simple, because they were mostly pointing Sidekick at endpoints their app already had.

Action extensions

An action extension loads part of your app, pre-filled and ready, so the merchant can execute an action. Sticking with the email example: a merchant says "create a new campaign," Sidekick recognises your registered create-campaign action, and pre-fills it as best it can from the available data.

Crucially, Sidekick does not execute the action for the merchant. Anything that mutates or creates something is staged, and the merchant has to confirm ("send", "create") before it happens. For any non-read action, the merchant stays in the loop. As Ethan put it: no YOLO mode for Sidekick.

The theme of Editions 2026: channels are multiplying

The headline of this year's Editions is that the places people shop, and the ways they discover products, are multiplying. It is the next step in an evolution developers have watched for years: single channel (your online store), then multi-channel (adding a marketplace), then omni-channel (marketplaces, POS, B2B), and now agentic channels: ChatGPT, Claude, Gemini, and others.

Two of the biggest developer-facing pieces support exactly this shift: the Product Catalog API and UCP.

The World Wide Product Catalog API

The Catalog API exposes millions of Shopify merchants and billions of products through a single search endpoint. The search is designed to handle natural-language questions like "find me all pizza ovens that fit two pizzas" and return real answers.

It also clusters results. Shopify identifies a canonical product (a universal product identifier) and groups the offers behind it, which means for a branded product you can effectively see a price comparison across the merchants selling it.

You get real filtering on top of search, including:

• Ships-to country (for example, only products that ship to Germany, or only to the US)
• Minimum and maximum price
• Attributes like color

The interesting part is what this unlocks. You can define a catalog in the dev dashboard that narrows down to a specific set of shops, search terms, price range, and shipping constraints, then build a bespoke consumer experience on top of it. Ethan's example: a site for pizza-making enthusiasts, curated down to ovens, peels, and books from a chosen set of stores. In an era where you can spin up a site or app quickly, that is a powerful primitive.

UCP: the Universal Commerce Protocol

If the Catalog API is about discovery, UCP is about actually transacting. The Universal Commerce Protocol is an open protocol built by Google, Shopify, Wayfair, and others, designed to be the lingua franca of commerce.

Every storefront that implements UCP (and all Shopify stores support it de facto) can be introspected by an agent, have a cart built on it, and hand off to checkout. The flow looks like this:

• Query the Shopify catalog to find products
• Introspect any UCP-speaking merchant
• Build a cart, adding line items with context
• Get back a cart plus a URL where checkout can continue on the merchant's site

Because it is an open protocol, you can assemble a cart with products from multiple merchants, as long as they all speak UCP, inside a single experience. This is the early version, so there are still details to work out (mixed carts across stores bring shipping questions you would handle in your own application). Shopify provides the infrastructure; what you build on top is up to you.

The UCP CLI

To make UCP approachable, Shopify shipped a UCP CLI. From the command line you can:

• Search the catalog completely unauthenticated (same natural-language search, with all the filters)
• Create a cart for a chosen merchant and add line items to it
• Get back a checkout URL

Ethan's analogy is a good one: think of how a browser implements HTTP to talk to servers. The CLI does the equivalent plumbing so your agent can talk to any site that speaks UCP, without you having to build all of that introspection tooling yourself. It is a natural fit for chat apps, support apps, and search-based experiences.

Is agentic commerce actually happening?

Short answer: yes, and it is measurable. Shopify shared on its last earnings call that it has seen a year-over-year increase in sales coming through generative channels.

Commerce is unusually well suited to these channels because discovery gets better. You can have a conversation ("I'm looking for something to cook multiple pizzas at once, gas or wood-fired?") that would have been awkward with a traditional search box, and once you have found the product you get deep-linked straight to it, ready to buy. Fully autonomous purchases are still a trust question (you might let an agent buy a USB cable, but maybe not a pizza oven yet), but the discovery-to-purchase path is already working.

Static apps: host your app fully on Shopify

Static apps let you host an app completely on Shopify, and right now they are free of charge. They solve a very common problem.

Plenty of apps really only need a configuration or customization surface. Take an agency building custom discounting with Shopify Functions, where the merchant needs a few toggles (a volume-based rule, say). Previously the agency would have to build the app and host a server running an iframe as the embedded app, just to serve that configuration, then maintain that server essentially forever.

Static apps remove that burden. You get an app home powered by Shopify's UI extensions, supporting all the components a UI extension supports, plus direct API access. You ship your HTML, CSS, JavaScript, and even static images, and Shopify fully hosts and runs the app. Beyond configuration pages, think bespoke editors (for example, a custom UI for writing a metafield onto a product). It is ideal wherever you want to give a merchant a simple, self-contained surface without owning infrastructure for it.

Transparent app pricing (a new pricing model)

The last big update is a new app pricing model. The old billing API was a fairly simple credit-and-debit mechanism, and while it was powerful, usage-based fees often ended up opaque to merchants. If your app charged $19/month plus a usage fee (per thousand emails or SMS sent, say), merchants did not get a clear picture of what all the charges added up to.

The new model takes the existing managed (monthly recurring) pricing and adds a usage-based component:

• A developer sets up meters in the partner dashboard (for example, emails sent at 10¢ per thousand, SMS at 20¢ per thousand)
• That pricing is displayed properly on the App Store page and cascades into the install experience
• At runtime, you increment the meters using the app event API (not to be confused with the events system above)
• Shopify aggregates usage and produces a monthly bill that breaks down exactly what the merchant is paying for

The result is simpler pricing for developers to build and real transparency for merchants, much like the usage page on the AI tools you already pay for.

Watch the full interview

We covered a lot in about half an hour. If you build on Shopify, the full conversation is worth watching: