Catalog Service and Live Search in ACCS: How Product Data Really Flows

Magento developers moving to ACCS often ask one thing first. Where does the storefront actually get its products from? It isn’t MySQL. It isn’t OpenSearch either. Once you see the real path, a lot of strange bugs suddenly make sense. This post explains Catalog Service and Live Search in ACCS: how product data flows and what to check when it breaks.

It’s part of my ACCS series. If you’re new here, start with the introduction to ACCS and the Edge Delivery Services storefront guide. This one sits right between them. It covers the data layer that feeds every product page and search box.

Facts below come from Adobe’s Catalog Service overview, the Live Search guide and the Storefront Services GraphQL docs. The GraphQL snippets are illustrative. I wrote them from the documented schema, but I haven’t run them against a live ACCS tenant. Where I’m not sure, I’ll say so.

What Catalog Service and Live Search actually are

Adobe groups three SaaS services under the name Storefront Services: Catalog Service, Live Search and Product Recommendations. Each one exposes its own GraphQL schema. That schema is separate from the core Commerce GraphQL you already know.

Catalog Service in one paragraph

Catalog Service is a read-only GraphQL API for product data. It returns product details, attributes, inventory flags and prices from a dedicated, optimized data store. Adobe cites up to 10X faster catalog queries compared to core GraphQL. It also simplifies product types. Simple, virtual, downloadable and gift card products become SimpleProductView. Configurable, bundle and grouped products become ComplexProductView.

Live Search in one paragraph

Live Search replaces the default Commerce search. It handles search-as-you-type, product listing pages, facets, synonyms and merchandising rules. Its main query is productSearch, and it returns facets alongside results. On top of that, it can re-rank results using shopper behavior. Adobe calls this intelligent ranking.

Product Recommendations is the third piece. It surfaces AI-generated units like “customers who viewed this also viewed”. The storefront docs still call these Adobe Sensei units.

How product data really flows in ACCS

This is the part that trips people up. Your storefront never reads products straight from the Commerce database. Here’s the path, step by step.

1. You edit a product in the Commerce Admin, or an import or API call changes it.
2. SaaS Data Export picks up the change. This extension builds “feeds” for products, attributes, prices, variants, categories and scopes.
3. The feeds go to Adobe’s SaaS data space. Cron-driven partial syncs keep it current and retry failed items automatically.
4. Catalog Service and Live Search index that data. Live Search builds its search index, including facets and synonyms.
5. Your storefront calls the services endpoint. PDPs use products, PLPs and search use productSearch.
6. Cart, checkout and account calls go elsewhere. They still hit core GraphQL, because the services schema has no mutations.
7. Storefront events flow back. Views, clicks and add-to-cart events feed the AI ranking and recommendations.

So there are two read paths and one write path. That split explains why a fresh Admin price change can look stale on the PLP. The storefront is reading an indexed copy, not the source.

How fast is “a while”?

Adobe’s Live Search setup guide says incremental product updates can take up to 15 minutes to reach storefront search after the initial sync. The Storefront Services docs are also blunt about it. Don’t use these queries when you need real-time inventory or pricing, because the data is indexed asynchronously. Plan your UX with that in mind.

Catalog Service and Live Search in ACCS vs PaaS

On PaaS, all of this is something you install. On ACCS, it’s already there. That difference sounds small, but it changes who does what on a project.

One caveat on the last row. The Storefront Services docs say ACCS includes the services, but the merchant must still configure Live Search and Product Recommendations. “Built in” doesn’t mean “tuned”. You still own facets, rules and events.

Planning a move? Pair this table with my PaaS to ACCS migration checklist.

Catalog Service vs core GraphQL vs Live Search

Developers coming from Magento usually reach for the core products query. That still works for some things. However, it isn’t what the EDS storefront uses for catalog pages. Here’s how I think about the three.

Illustrative queries you’ll actually write

These are illustrative snippets based on Adobe’s documented schema. Field names can change between releases, so check the reference before you copy them into a drop-in or a mesh.

1. Product detail data from Catalog Service

The Catalog Service products query takes SKUs, not a search filter. That’s a big mental shift from core GraphQL. Adobe’s products query reference shows the full shape.

# Illustrative: Catalog Service products query (PDP)
query ProductDetail {
  products(skus: ["MH07"]) {
    __typename
    sku
    name
    url
    inStock
    images(roles: ["image"]) { url label }
    attributes(roles: ["visible_in_pdp"]) { name label value }
    ... on SimpleProductView {
      price { final { amount { value currency } } }
    }
    ... on ComplexProductView {
      options { id title values { id title } }
      priceRange {
        minimum { final { amount { value currency } } }
        maximum { final { amount { value currency } } }
      }
    }
  }
}

2. Search with facets from Live Search

This one powers a search results page. Notice that you ask for productView, not the deprecated product field. The productSearch reference explains both.

# Illustrative: Live Search productSearch with facets
query SearchJackets {
  productSearch(
    phrase: "jacket"
    page_size: 12
    filter: [
      { attribute: "price", range: { from: 50, to: 100 } }
      { attribute: "size", in: ["M", "L"] }
    ]
  ) {
    total_count
    page_info { current_page total_pages }
    facets {
      attribute
      title
      type
      buckets {
        title
        ... on ScalarBucket { id count }
        ... on RangeBucket { from to count }
      }
    }
    items {
      productView { sku name urlKey }
    }
  }
}

3. Category browse with merchandising rules

For category merchandising rules to apply, Adobe says the query must filter on categoryPath, sort by position and send an empty phrase. Miss one of those, and your carefully pinned products won’t show.

# Illustrative: category page that respects category merchandising
query CategoryPage {
  productSearch(
    phrase: ""
    filter: [{ attribute: "categoryPath", eq: "women/bottoms-women" }]
    sort: [{ attribute: "position", direction: ASC }]
    page_size: 24
  ) {
    items { productView { sku name } }
    facets { attribute title }
  }
}

All three go to the services endpoint with store context headers like Magento-Store-Code, Magento-Store-View-Code and Magento-Website-Code. Catalog Service also wants Magento-Customer-Group for pricing.

How Live Search decides what to show

Live Search does more than match text. Knowing the layers makes tuning much easier.

• Matching: it runs an exact search first. If nothing comes back, it retries with a fuzzy search that allows one typo per word.
• Facets: only attributes you configure as facets in Live Search come back in facets. Filtering on an attribute that isn’t filterable in search returns a 500 error.
• Synonyms: you map shopper words to catalog words, so “sofa” can find “couch”.
• Merchandising rules: if-then rules that pin, boost or bury products for a query or a date range.
• Intelligent ranking: strategies like Most purchased, Most viewed, Trending and Recommended for you. They blend behavioral signals with text relevance.
• Semantic search: matches by meaning for natural-language queries. It’s on by default in ACCS for English catalogs.

Adobe’s rules documentation is clear that text relevance stays the dominant factor in search. Behavioral signals add a bounded boost, which you can tune per rule. In other words, AI ranking won’t rescue a product with a poor name and no description.

Where EDS drop-ins and API Mesh fit

On ACCS, your storefront is usually Edge Delivery Services with Adobe’s drop-ins. According to the Commerce services overview, the Product Details drop-in needs Catalog Service. Live Search powers the Product Discovery drop-in for search and PLPs.

The storefront config has two endpoint keys. commerce-endpoint is the read-only services endpoint, and commerce-core-endpoint handles writes. For ACCS, Adobe’s storefront configuration docs say you only need commerce-endpoint, because the same ACCS URL serves both catalog and core. That’s a nice simplification compared to PaaS.

API Mesh is optional. Reach for it when you want one endpoint over core GraphQL, Catalog Service and a third-party API. It also lets you add custom fields to ProductView. Adobe suggests Mesh for complex price logic too. I covered why this out-of-process approach matters in ACCS vs PaaS custom modules.

Troubleshooting and common gotchas

Many Live Search problems turn out to be data or config issues. Here’s where I’d look first.

Stale prices or stock

Remember the indexed copy. First, open System > Data Transfer > Data Feed Sync Status to confirm the feed exported. Then check the Data Management Dashboard to confirm delivery. Adobe’s sync guide covers both pages and manual resync options.

Facets missing or a 500 error

Check two things. Is the attribute filterable in search? And is it configured as a facet in the Live Search workspace? Some internal fields, such as inStock, can filter but can’t become shopper-facing facets.

AI ranking does nothing

Intelligent ranking needs storefront events. On a headless or EDS storefront, event collection isn’t automatic the way it was in Luma. If events aren’t flowing, the models have nothing to learn from.

Products missing from search

Adobe notes that products returned by Live Search must be assigned to a category. Also check visibility and the store view headers you send. A wrong Magento-Store-View-Code quietly returns the wrong catalog.

Empty results on a quiet sandbox

If a testing environment gets no search queries for 90 days, its catalog data hibernates and returns nothing. You need a support request to reactivate it.

Pagination limits

productSearch can paginate a maximum of 10,000 products for any query. Large B2B catalogs should design filters with that in mind.

A quick checklist before go-live

• ☐ Confirm all feeds show success on the Data Feed Sync Status page.
• ☐ Spot-check prices and stock in the Data Management Dashboard.
• ☐ Configure facets for every attribute your PLP filters on.
• ☐ Add synonyms from real search terms, not guesses.
• ☐ Set a default search rule and test it in “Test your rule”.
• ☐ Verify storefront events reach the Live Search dashboard.
• ☐ Check that category pages sort by position where merchandising matters.
• ☐ Send the right store, website and customer group headers.
• ☐ Keep cart and checkout on core GraphQL, never on the services endpoint.

FAQ

Do I need to install Catalog Service or Live Search on ACCS?

No. Both are included in ACCS. You still configure Live Search and Product Recommendations, though, including facets, synonyms and rules.

Can I use the core products query instead?

You can, but the EDS drop-ins are built around the services endpoint for catalog data. Core GraphQL remains the place for cart, checkout and customer operations.

Why does a product change take time to appear?

Because the storefront reads an indexed SaaS copy. Adobe says incremental updates can take up to 15 minutes to reach search after the initial sync.

Is Live Search the same as Adobe Sensei?

Not exactly. Live Search is the search service. Its intelligent ranking and Product Recommendations use Adobe’s AI models, which older docs call Adobe Sensei.

When should I add API Mesh?

Add it when you need one endpoint over several sources, or custom data on product views. For a standard EDS storefront, you may not need it at all.

My take

The biggest shift isn’t the GraphQL syntax. It’s accepting that the storefront reads a copy of your catalog, not the catalog itself. Once your team internalizes that, debugging gets faster and expectations get saner.

ACCS makes the plumbing someone else’s problem, and honestly, I like that. But you still own the quality of the data and the search setup. Good attributes, real synonyms and working events matter more than any ranking toggle.

If you’re still deciding on a platform, read ACCS vs Adobe Commerce on Cloud next. And if you’ve hit a Live Search quirk I didn’t list, drop it in the comments. I’ll keep adding to this post.