Shopify Editions Spring '26: Agentic | Opening Up the AI Commerce Foundation (All 11 Items)

From listing via AI channels all the way to visualizing results, this lets you handle everything together on the admin side (Agentic home). You could call it "the front door to agentic commerce."

It refers to the places where AI mediates shopping — ChatGPT, Copilot, Gemini, Perplexity, the Shop app, and so on. Instead of the traditional "drive people to your own online store," from here on products are found within conversations with AI assistants and lead to purchases — and those "listing destinations" are AI channels. Note that "discovery (finding things)" happens broadly across all these channels, but whether you can "complete checkout inside the conversation" varies by channel (see "Checkout in more places" below).

1. The merchant registers products in Shopify (ordinary product data).
2. Shopify Catalog automatically standardizes and enriches that data and places it in the global catalog.
3. AI channels / external agents discover, recommend, and sell the products across the Catalog API (UCP).
4. Orders and results can be reviewed in the admin's Agentic home and elsewhere.

The official demo video shows that this goes beyond mere "automatic listing" — you can actually run operations and optimization from the admin side. The key points are as follows.

• Automatic listing and order sync: Products are automatically listed on AI channels such as ChatGPT and Copilot (discovery), and on channels that support checkout, buyers purchase within the conversation. Orders sync straight back into the Shopify admin. Note that ChatGPT runs primarily on the ACP (Agentic Commerce Protocol, a separate lineage led by OpenAI and Stripe; see "Checkout in more places" below) and centers on discovery, while completing in-chat checkout with Shop Pay happens on UCP-supported channels (such as Copilot) — that's the difference.
  Related: The AI Commerce endpoints Shopify had been auto-deploying to every store ／ Preparing for the era when AI picks your products
• Agentic overview (a single, unified dashboard): Track the sales, session counts, order counts, and conversion rate of the major AI channels all in one place.

  

• High CVR from high-quality data: The Shopify catalog organizes and translates the context of each product, providing accurate structured data — not scraped data. As a result, the conversion rate is said to be about twice the usual (please confirm the preconditions for that figure in the source).
• Search insights + Sidekick suggestions: You can see what buyers are actually searching for in AI chat, reproduce the searches the AI uses, and check whether your products rank. Areas that need improvement are flagged, and Sidekick suggests the specific changes to make.
• Listing preview and channel control: With one click, open a pre-filled search and preview how products look to buyers. You can also set, from the admin, which AI channels you supply data to, and whether distribution is automatic or controlled individually.

"Listing for AI" looks less like a set of individual optimization tasks and more like something that boils down to the quality of your product data. In the end, what you do is "flesh out the descriptions, specs, images, and taxonomy." Rather than treating AI-channel readiness as something special, you can unify the message: "tidying up product data = AI readiness."

This is the technical foundation underneath the previous item (Products optimized for AI). Shopify normalizes the product data that merchants write in all sorts of inconsistent ways into a unified format, and further fills in information with machine learning (enrichment) — you could call it "a layer that quietly tidies up the data so AI can understand products correctly."

The data returned by the Catalog API includes, in addition to the merchant's own input, metadata (ML-inferred metadata). The keys I was actually able to confirm are as follows.

• tech_specs (technical specifications)
• top_features (top features)
• unique_selling_points (unique selling points)
• attributes (normalized attributes such as material, style, and occasion)

We can tell these are machine-learning inferences first because it's stated explicitly in the official extension spec (Global Catalog extension). That document defines each field under product.metadata with "ML-inferred" prefixed to all of them.

• attributes: "ML-inferred product attributes such as material, style, and occasion."
• tech_specs: "ML-inferred technical specifications."
• top_features: "ML-inferred top product features."
• unique_selling_points: "ML-inferred unique selling propositions."

None of these are described as "fields the merchant edits directly," so we can read them as read-side data that Shopify generates automatically. On top of that, I confirmed that the same keys actually come back when you call the API (see the next code block). In other words, it's backed up on both sides: not just "the spec says so," but "it really does return that way."
* In the spec, fields like tech_specs are defined as string arrays, but in actual responses I also saw cases where they came back as a single string with line breaks (this area should be verified against live data).

When you actually call the global catalog API (search_catalog at POST catalog.shopify.com/api/ucp/mcp), this data comes back inside each product's metadata. Below is an actual response for a certain pair of wireless headphones (Sennheiser MOMENTUM 4), cleaned up and partially abbreviated for readability.

// search_catalog response → products[].metadata (live data, partially abbreviated)
{
  "unique_selling_points": [
    "Hybrid adaptive noise cancellation and transparent mode for
     seamless situational awareness and immersive sound."
  ],
  "top_features": "Hybrid adaptive noise cancellation: ...\n
     Customizable sound modes and EQ presets: ...\n
     Premium comfort design: ...\n
     Up to 60 hours battery life: ...\n
     Smart Pause and auto on/off: ...",
  "tech_specs": "Wearing Style: Headband, around the ear (Circum)\n
     Connectivity: Bluetooth 5.2, 3.5 mm, USB, 2.5 mm\n
     Speaker Type: 42 mm dynamic transducer\n
     Frequency Range: 6 Hz to 22 kHz\n
     Battery Life: Up to 60 hours (Bluetooth + ANC)\n
     Charging Interface: USB Type-C\n
     Microphone: MEMS, 2-microphone beamforming"
}

For reference, the above can be read as follows in plain terms (the response itself is in English).

What's worth noting is that this is not the raw description text the merchant wrote. The key points have been bulleted, and tech_specs has been formatted as "field name: value." You can see that a machine reconstructed it from the description, spec table, images, and so on. The types also differ by key: unique_selling_points was an array, while top_features / tech_specs were line-break-separated strings.

Shopify states that "data structured through Shopify doubles the conversion rate (CVR) in AI chat." This is likely because normalized, consistent data improves matching accuracy — for instance, the AI can treat the same "mid-century" with the same meaning, or brass lamps get tagged consistently (please confirm the assumptions behind the figure in the source).

1. The merchant registers a product → Shopify maps it to taxonomy and attributes (standardization).
2. ML infers tech_specs / top_features and the like from the description, images, and so on (enrichment).
3. The consolidated data is placed in the global catalog and returned, deduplicated by UPID (a common product ID) — that is, the same product registered by different stores is merged into one.

The true nature of "AI optimization," I feel, ultimately comes down to tidying up product data. Since it's ML inference, the idea of stuffing in keywords doesn't work well; what works is the quality of the raw material (descriptions, specs, images, classification). Put another way, making product data healthy is itself the first step toward AI commerce readiness, and tidying up taxonomy, entering attributes, and enriching images/specs all look like initiatives worth tackling head-on.

This is the mechanism that lets shoppers complete the "payment" inside the AI conversation, without having to come to your own site. On supported channels such as Copilot, saying "buy this" takes the purchase all the way to completion right there using Shop Pay — you could call it the "last piece" of agentic commerce.

Agentic commerce is a three-stage structure of "discovery → cart → payment," and this item corresponds to that final "payment" stage. The foundation is the various MCPs of UCP (see the next item).

The three demos I published (Concierge / Search by image / URL price check) went as far as producing a checkout_url and sending the user to each store's checkout screen. This item goes a step further, into a world where you go all the way to payment without leaving the chat.

It's marked "coming soon / planned." Support for Copilot and the like, as well as Meta ads integration, is described as a phased rollout. We can't assert "you can buy with Shop Pay in any chat right now"; it's more accurate to read it as certain in direction but fluid in timing.

Once this is in place, "having AI buy for you" becomes literally real (discovery → payment, all inside the conversation). The key is the spread of Shop Pay, and stores that have enabled Shop Pay look more likely to reap this benefit automatically. On the other hand, building your own fully automated checkout is hard to implement (Token tier + permissions), so for the time being the realistic answer looks like "riding on the payment path that Shopify / the AI channel provides."

Until now, Shopify has been "a platform for building online stores." The Agentic plan is a new entry point where you can sell on AI channels by putting only your product data into Shopify, without having an online store. It looks like a fairly significant shift in direction — Shopify expanding from a "store-building tool" into "the product-supply infrastructure for AI commerce."

1. You don't build an online store. But you do create a Shopify account.
2. Add products (manually / via CSV / via the Admin API, or by integrating with your own PIM (Product Information Management system)).
3. Shopify syncs the products to AI channels (ChatGPT / Gemini / Copilot / Perplexity / Shop, etc.) in real time.
4. Orders are routed to your own OMS (Order Management System), and tax is handled via your tax-system integration.

In other words, it's a setup where you "don't keep a front (store) and use Shopify solely as an 'AI-facing sales channel and catalog.'"

No monthly fee — only transaction fees. For online transactions in Japan it's 3.55% + ¥0 (rates vary by region). Since there's zero fixed monthly cost, the barrier to "just trying AI channels first" looks low.

• Cases where mid-to-large businesses that already have their own EC or core systems want "exposure on AI channels only, without fully migrating to Shopify."
• As a channel for manufacturers / wholesalers to feed products from their own PIM into AI commerce.

This looks like an item that breaks the fixed notion of "Shopify = building a store." Being able to say, in a pitch, "no store migration needed — you can put products on AI channels with just product data" could be a big deal. The crux is PIM integration, and for businesses with a product-data foundation, the value of tidying up that data ties in directly. On the other hand, "having no front = a thinner, less crafted brand experience" is a risk, so there seems to be room to discuss the design — for example, running your flagship store alongside the Agentic plan.

UCP is an open protocol (a common standard) for AI agents to conduct commerce safely on behalf of buyers. Co-developed by Shopify and Google, it's also backed by Amazon, Meta, Microsoft, Salesforce, Stripe, Etsy, and others. It aims to be "the common language of AI commerce," and all the other agentic items sit on top of it. It's implemented as three MCPs (Model Context Protocol) — catalog (discovery), cart, and checkout — and you can think of it as Shopify providing a "common language" that isn't tied to any particular AI.

There are two layers of endpoints. A global one that spans all merchants and is discovery-only (POST https://catalog.shopify.com/api/ucp/mcp), and a storefront one that handles discovery plus cart/checkout for a single store (https://{shop}.myshopify.com/api/ucp/mcp). A business profile is auto-generated at each store's /.well-known/ucp (one existed for STORE DOJO as well).

• JSON-RPC 2.0. Pass method:"tools/call", the tool name in params.name, and the agent profile URL (required) in arguments.meta["ucp-agent"].profile.
• No approval — and not even an API key — is required for discovery (this is the heart of Spring '26's "general opening up").
• For calling directly from the browser, use Content-Type: text/plain. With application/json, the CORS preflight (OPTIONS) is rejected, but with text/plain you get 200 + ACAO:* and can read the response (the server interprets it as JSON).
• Test profile: shopify.dev/ucp/agent-profiles/2026-04-08/valid-with-capabilities.json (for permanent public pages, a self-hosted profile is recommended).

With this knowledge, I was able to build and publish STORE DOJO's three demos (Concierge and others) serverlessly.

Discovery (Catalog) is generally available (GA-equivalent) and can be called without approval. Cart / automatic checkout finalization (complete_checkout), on the other hand, requires the Token tier + permissions.

This looks like the center of the agentic strategy. Shopify becomes the "orchestration layer (the conductor)," and external AIs conduct commerce via this protocol. The fact that it's an open standard rather than one company's lock-in is significant, and it feels like it's becoming the de facto common standard for the industry. What's more, implementation is surprisingly lightweight (no API key needed, callable from the browser), so the low psychological barrier to a PoC (Proof of Concept) is also a practical advantage.

1. When you pass placements:["affiliate"] to search_catalog, promoted products come back mixed in with the regular (organic) search results.
2. You can identify "this is a promoted item" by each product's placement.commission (organic ones have no placement field).
3. A shdid (developer ID) / shclid (click ID) is appended to the URL, and a purchase within 7 days of the click is measured as a conversion → paid out monthly after KYC (identity verification).

Hands-on result: when I sent placements:["affiliate"] with a test profile, there were 0 promoted items. In other words, it seems they don't appear unless you're enrolled in the Developer Preview (invite-only).

"So is it a free-for-all where you can flood the results?" — apparently not. There's a relevance gate, so unrelated products don't appear. The commission rate is controlled by the merchant, and in the first place a product has to be in the catalog-search candidate set for any of this to matter (structuring product data is the prerequisite). Unlike listing ads (CPC bidding), it leans toward performance-based.

Developer Preview (invite-only). It's not something ordinary merchants / developers can use right away.

If you build "an agentic experience that compares and recommends," there's a path to monetization — it looks like the "AI version" of affiliate models on media / comparison sites. But the big prerequisite is "product data that makes it into the candidate set in the first place," so it lands back on the data-tidying story after all. Since it's currently a preview, I felt the honest approach was to introduce it in the article as a "future revenue model" and not let readers misread it as a way to make money right now.

What "Shop sign-in support" really is, is a mechanism called a buyer-linked token available at the top of the three auth tiers, the Token tier. That's why the source is an "authentication" page.

Simply put, it's a "signed-in token" carrying the Shop-customer information of "who this person is" (a Shop customer = a user of accounts.shop.app, which includes Shop Pay users and numbers around 250 million worldwide). When you pass this to catalog search, the search enters a "state where it knows who it's dealing with," and can be personalized for that person. The flow to obtain one is three steps: ① get login permission from Shop → ② exchange it for a short token meant for redemption → ③ redeem it for the actual token at Shopify (a "delegation method" following the standard OAuth spec). The advantage is that you don't have to show a second login screen (the existing Shop login is carried over on the server side), and the token you obtain is valid for 60 minutes and cannot be reissued.

This looks like a mechanism that lets you delegate "the AI-commerce version of signed-in recommendations" to Shopify's catalog without holding any ML yourself. That said, it presupposes a server + a Dev Dashboard app, so it won't roll out to all merchants right away. For now, the realistic stance seems to be "nail down the design of the plumbing (server + app)" and prepare so you can deliver value the moment personalization launches.

This is a showcase of "what kinds of experiences you can actually build with the Catalog API + UCP." Shopify officially introduces several demo apps.

I proved out this item on my own store. All of them call the global catalog serverlessly (directly from the browser, with text/plain).

• Omakase Concierge (situation → outfit suggestions)
• Search by image (Visual Search)
• Price check by URL (Price Lookup)

As an honest note, in these the "finding" is done by the Shopify catalog, and the "selecting (ordering)" is done by simple queries + rules — there's no LLM judgment involved. The fact that they're still accurate is, I feel, largely down to the performance of the Shopify catalog side.

Experiences you can build with discovery are implementable right now (no approval needed), and I was actually able to publish them. Completing payment inside the conversation (Checkout in more places) and personalization (Shop sign-in support) require a server + authentication.

I came to feel that a "demo you can touch" is the strongest sales material. You can show abstract AI commerce on a page that actually works. Being buildable serverlessly — i.e., low production cost — is also an advantage. On the other hand, a "page that merely guides you" is something anyone can build and is hard to differentiate, so the value ultimately resides in the quality of your own product data and the design of the experience.

If you pass the image itself to search_catalog, it returns products that look similar. You can search by image for "clothes with this vibe" or "a bag this shape" — things that are hard to put into words.

• The parameter is catalog.like (an array, up to 2 elements). Each element is {image:{content_type, data(base64)}} (or the {id} of a known product).
• Combine it with query (text) and it becomes multimodal search (image + words).
• Extracting image features and computing similarity is done on Shopify's server side (a mechanism that converts an image into feature values — a sequence of numbers — and matches against them; technically these are called embeddings). That is, you don't need to hold any AI / machine learning on your side, and the base64 is merely a transmission format that replaces the image with text.

It's safer to shrink the image before sending (max 1024px, converted to JPEG). If it's too large you get a Service error (tested: 4000×4000 → shrink → base64 of about 12KB → 200 OK). To narrow down to Japan shipping and Japanese yen, the reliable approach is to re-filter the returned values on the client side with price.currency==='JPY' && availability.available.

Being able to build a "search by photo" UX without your own ML feels like a big deal. It seems well-suited to apparel, miscellaneous goods, and interiors. Since the source of accuracy is the Shopify catalog side, in the end what matters is whether your products are loaded "visually correctly" (good images, normalized data). The path of "photo from a video / SNS / magazine → similar in-stock product" becomes viable, and there seems to be potential to digitize the in-store request "find me something like this."

In contrast to search_catalog (find by criteria), lookup_catalog is a converter (resolver) that "brings an already-known product up to date." Pass a product ID or a Shopify product URL and it returns the current price, inventory, variants, and purchase link. The key point is that it isn't crawling / parsing the page — it's just doing an identifier → catalog-data conversion.

What you can pass to catalog.ids (1–50 items) is gid://shopify/p/{upid} / gid://shopify/ProductVariant/{id} / an http(s) Shopify product URL (custom-domain stores are fine too).

Passing a product URL immediately returns price{amount,currency} / availability{available} / seller / checkout_url / condition, while unresolvable IDs go to not_found. As a currency caveat, if you fix context.address_country to JP, stores that don't ship to Japan get silently excluded (a sample of 4 → 2), so I found that for a price-checker use case the correct approach is to add no country and display each store's local currency (confirmed in the price-check demo).

Rather than a human pasting a URL, its true value looks like being a behind-the-scenes API for AI agents. The AI takes a product link pasted in a review / SNS / YouTube description, converts it into structured data instantly without scraping → compares and recommends → connects to the Cart / Checkout MCP and goes all the way to "go ahead and buy it." The officially envisioned uses are also "resolving IDs from search results, or from links (deep links) that go straight to a product page" and "checking whether the products in the cart are still at the correct price and in stock."

It's positioned as the agent's "product-identification" component. It's effective after discovery (search), or as a starting point from external links. The demo page is a "showcase that visualizes a behind-the-scenes API," and its value to humans is limited, but I found it useful as material for explaining AI integration. The point that a group of identical URLs gets merged into one product via UPID deduplication ties directly into the next item, "Rich product data."

This isn't a new tool; it's a "data quality" story — that the product data the Catalog API returns carries enough information for an agent to judge, compare, and complete a purchase. The four elements listed for this item in Shopify's Editions announcement (media, variants, listing status, offers from multiple sellers) aren't mere marketing copy — they correspond directly to fields in the data the Catalog API returns (see the table below).

By the official definition, search results are "deduplicated by Universal Product ID (UPID) and include offers from multiple sellers." That is, the "same product" that stores around the world registered separately is consolidated by Shopify into one and returned. In testing too, within a single "AirPods Pro 3rd Gen" (one UPID), prices from multiple sellers lined up.

Multiple companies' prices line up within a single product entry → the agent can compare for the lowest price right there (the catalog version of Amazon's seller list). On top of that, each product carries ML-inferred metadata (tech_specs / top_features / unique_selling_points; detailed in this article's "Structuring product data" item).

After finding a product via search, passing it to get_product (id required) gives you the full details of one product + variant narrowing. Using selected (the currently selected options, e.g., Color=Blue, Size=10) and preferences (the order in which to compromise; e.g., ["Color","Size"] relaxes Size first), the design lets you work through "which colors are in stock in size M?"

In the agent era, the product page looks set to compete as "one row in a list of multiple offers." It's a structure where you're chosen on price, inventory, and the richness of your data. Since fields like top_features are ML-inferred rather than typed in by hand, the winning path ultimately comes down to the richness of the underlying data (descriptions, specs, images, taxonomy, attributes). The fact that my three demos display seller / price / availability / checkout_url is precisely a worked example of visualizing this "rich product data."