Executive summary
- What: The updateCart standard action now writes cart attributes, and a new shopify:cart:attributes-update event fires whenever an attribute change is initiated.
- Why: Changing an attribute previously meant calling the Storefront API directly, and nothing on the page was told when a key changed.
- Who: Teams shipping delivery date pickers, gift options, engraving fields, subscription selectors, or any app that reads or owns a cart attribute.
What changed
Two things landed together. The updateCart standard action now accepts attributes alongside lines, note and discount codes, so a single call can change several parts of the cart at once. And a new event, shopify:cart:attributes-update, fires whenever an attribute update starts, regardless of whether your app, the theme, or another app triggered it.
Three details govern how you write against this. Attributes replace rather than merge, so the set you send becomes the complete set: omit an existing key and you delete it, send an empty array and you clear everything. The resolved cart does not include attributes, so read back what you submitted. And the event fires when the operation starts, carrying a promise for the result.
That last point is deliberate rather than awkward. You can apply the change to your interface immediately and revert if the promise rejects or resolves with userErrors. A declined change does not throw, so check that array before you read the cart. A failed request rejects the promise and dispatches shopify:cart:error.
Why it matters
Before this, an app that owned a cart attribute had to post to the cart itself and had no way to learn that another app or the theme had changed the same key. Two failure modes followed. Attribute clobbering, where the last writer wins and silently drops another app's key, and stale interface state, where a delivery date picker displays a value the cart no longer holds. The event closes the notification gap, and the standard action means your code no longer has to know how the cart is rendered, which is exactly the assumption that breaks when a theme is updated. If you maintain custom apps that extend the cart experience, this is the moment to revisit how each one claims and releases attribute keys.
For Plus merchants running several cart-adjacent apps, treat this as a stability change rather than a new capability. The attributes were always writable. What was missing was a contract between the parties writing them.
Role-specific impact
- Marketers: Cart-level personalization such as gift messaging, delivery windows and engraving becomes more reliable, so campaigns built on those fields stop leaking conversions.
- Developers: Replace direct Storefront API attribute writes with updateCart, subscribe to the new event, and send the complete set on every write. Budget time for a merge strategy, because replace semantics punish partial writes.
- Store admins: Expect fewer support tickets caused by orders arriving with a missing delivery date or gift note, and fewer manual corrections before fulfillment.
Use-case example
Real-world scenario
Consider a furniture retailer running a delivery date picker in the cart drawer alongside a separate gift wrap app, both writing cart attributes. Because each sent only its own key, whichever wrote last cleared the other. Roughly 2 percent of orders reached fulfillment without a delivery date, and each cost a support touch plus a rescheduling call. With the new event, both apps subscribe to shopify:cart:attributes-update, keep a copy of the full set, and submit it on every write. The clobbering stops, and the picker reverts its display when the cart declines a change.
Implementation checklist
- Inventory every place your theme, apps and scripts write cart attributes.
- Replace direct Storefront API attribute writes with the updateCart standard action.
- Send the complete set on every write, since a partial payload deletes the missing keys.
- Subscribe to shopify:cart:attributes-update and keep a local copy of the current set in sync.
- Apply changes optimistically, then revert when the promise rejects or resolves with userErrors.
- Handle shopify:cart:error so a failed request surfaces instead of failing silently.
- Configure the action so your storefront refreshes its own interface rather than reloading.
- Test two apps writing attributes in the same session, the case that previously failed.
FAQ
Q: Will our existing Storefront API attribute writes stop working?
A: No, they continue to work. The tradeoff is that such code still has to know how the cart is rendered, and other apps on the page are not notified when it changes a key. Migrating to the standard action removes both problems.
Q: Does the event tell us which app made the change?
A: Not by name. It carries a context value of product, cart, dialog or standard-action, which tells you where the update originated. The standard-action value is reserved for events emitted automatically by standard storefront actions.
Resources
Cart attributes update event reference
Need guidance? Talk to Makro.