Themes / Developer Changelog

Standard storefront events and actions
A standardized "common language" between themes and apps

Liquid storefronts now include a standard communication layer between a theme and the code running on top of it. The theme emits eventswhile apps and agents call actions. Both work across all themes and ship as a set, so you only need to implement once.

On this page
  1. What actually changes (understand it in 30 seconds)
  2. How it works: the two-way flow of events and actions
  3. What's inside events (theme → app)
  4. What's inside actions (app → theme)
  5. Default action behavior vs. theme-side overrides
  6. 5 key points for developers
  7. 3 use cases you can apply to your work
  8. A one-line summary you can use in a pitch

1What actually changes

Until now, app developers had to decipher the DOM structures and events that differed from theme to theme in order to integrate.
Now, Liquid storefronts include a "standard communication layer" between themes and code , soevents (emitted by the theme) and actions (called by apps/agents) let them talk through a shared, two-way interface.

Before: built per theme

Apps parsed each theme's DOM and custom events individually. They broke when the theme changed, and every data fetch required an additional API call.

From now on: a standard interface

events / actions work across all themes. Implement once. Subscribing to events is plain JavaScript, and since the payload arrives directly, no follow-up API calls are needed.

2How it works: the two-way flow of events and actions

Theme (Liquid) Browsing products, updating the cart, searching and other such actions occur, then... emits a DOM event Apps / Agents Subscribe with plain JS → receive payload When you want to trigger theme behavior... Call an action event (no follow-up API needed) action = request a UI change When an action succeeds, it also fires the corresponding event (closing the round trip)
The key point is "Both work across all themes and ship as a set". Theme developers implement events and override actions. App developers subscribe to events and call actions. The roles are reversed, but you only implement onceby design.

3What's inside events (theme → app)

events are DOM events that represent "commerce operations." Theme developers implement them in the theme code, and app developers subscribe with plain JavaScript to receive the payload directly (no additional API calls needed).

shopify:product:view

Fires when a product is viewed. A starting point for view tracking and recommendations.

shopify:cart:lines-update

Fires when a cart line item is updated. For syncing cart contents and upsell suggestions.

shopify:search:update

Fires when a search is updated. For search-term analysis and suggestion integration.

The above are the 3 examples shown in the article. The article explicitly notes "and others(and more)", so events beyond these also exist.See the documentation for the full list.

4What's inside actions (app → theme)

actions are the reverse direction of events.Available on all Liquid storefronts, so apps and agents can call them to trigger theme behavior.

Shopify.actions.updateCart

Updates the cart. Call it when you want to modify cart contents from the app side.

Shopify.actions.getCart

Gets the current cart state. Use it as input for display or decision logic.

Shopify.actions.openCart

Opens the cart (drawer, etc.). For flows like showing the cart after adding an item.

DirectionCaller / ImplementerNature
events Theme fires / App subscribes DOM events representing commerce operations. The payload arrives directly
actions Theme provides/overrides behavior / App calls Available on all Liquid storefronts. Fires the corresponding event on success

5Default behavior of actions vs. theme-side override

Same updateCart But the experience changes depending on whether the theme overrides it. This is the crux of the feature.

Default (out of the box)

Storefront API + page reload

When the theme does nothing, the action calls the Storefront API and reloads the page. It reliably works, but the screen does a full reload.

action Storefront API reload
Override (theme implementation)

Updates the UI directly without reloading

When a theme developer overrides the action, it canskip the reload and update the UI directly. And on success it fires the corresponding event, so subscribers are notified naturally too.

action Update the UI directly (no reload) event
The app-side code is the same call in either case. Whether it's "with reload" or "without reload" depends on the theme implementation, and the app can use it without being aware of the difference. This is what "implement once" means.

65 points engineers should know

1. A shared layer that works across all themes

events / actions aren't tied to a specific theme—they're available across the entire Liquid storefront. The goal is to move away from per-theme custom builds and DOM parsing.

JS

2. Subscribe with plain JavaScript

Because events are DOM events, you can subscribe with plain JS, no framework required.The payload arrives directly, with no follow-up API call needed, which helps on both implementation and performance.

3. action success → event fired closes the loop

An action emits the corresponding event on success. In other words, "changes the app made" are also conveyed to subscribers uniformly, and thestate-sync loop stays consistent.

reload SPA

4. A two-tier setup of default and override

Out of the box it "just works" with Storefront API + reload. If the theme overrides it, you get a smooth, reload-free UI.The app-side call stays unchanged.

theme app

5. Agents (AI) are first-class callers too

The article explicitly states that "apps and agents" call actions. It's designed on the premise that AI agents can drive storefront behavior with standard actions, looking ahead to future automation and conversational purchasing UX. For the detailed spec, see thedocumentation.

73 use cases you can apply to your business

Theme A Theme B Implement once
USE CASE 1

Making analytics & tracking apps theme-independent

Problem
Tracking tags for product views, cart updates, and search are implemented by reading the DOM per store and per theme, so they break every time the theme changes.
Approach
shopify:product:view / shopify:cart:lines-update / shopify:search:update Subscribe with plain JS and forward the payload as-is to your analytics backend.
Impact
Analytics that doesn't depend on theme differences. You implement it once, lowering maintenance cost, and follow-up API calls disappear, making pages lighter too.
Technical notes
Coverage of events beyond the three examples shown needs to be confirmed in the docs. Validate the payload schema as well.
USE CASE 2

Making upsell / bundle apps reload-free

Problem
Add-to-cart apps do a full page reload after the equivalent of updateCart operations, breaking the experience and hurting CVR.
Approach
Have the app simply call the standard Shopify.actions.updateCartopenCart , and override the action on the theme side for reload-free UI updates.
Impact
A smooth add-to-cart experience. The app's code stays unchanged, and the optimal behavior is chosen automatically depending on whether the theme supports it.
Technical notes
When the action succeeds the corresponding event fires, so it stays consistent with other subscribing apps (analytics, etc.). It still runs safely with default behavior even on stores whose themes don't support it.
USE CASE 3

A "buy through conversation" flow powered by AI agents / chat

Problem
You want to enable "add this to my cart" from chat or an AI assistant, but implementing it by calling each store's cart API individually is heavy.
Approach
Have the agent call the standard Shopify.actions.getCart / updateCart / openCart . This is the by-the-book approach for the "apps and agents" use case the article describes.
Impact
You can roll out a conversational purchasing UX that works across all Liquid storefronts, without per-theme work.
Technical notes
The article doesn't document the exact signatures, coverage, or auth requirements of the actions / events. Be sure to confirm in the docsbefore implementing.

8A one-line summary you can use in pitches

"A common layer that standardizes the conversation between themes and apps/agents.
Themes fire events and apps subscribe with plain JS (no follow-up API needed); apps call actions and, if the theme overrides them, there's no reload.
It works across all themes and is implemented once. You can lighten theme-independent analytics, upsells, and AI purchasing flows all at once."