# Adobe Commerce Catalog Service on production catalogues Install magento/catalog-service, sync SaaS feeds, and point Magento PDPs at catalog-service.adobe.io so storefront reads stop hitting core GraphQL. - Date: 2026-09-14 - Category: Magento Adobe Commerce Catalog Service is the read-only SaaS GraphQL layer I put in front of Magento product and category pages when core `/graphql` is too slow to render a production catalogue. I am Alan Vo, a Gold Coast web developer with 18 years on Magento, Shopify and WooCommerce stores. This note is the production cutover: Composer, feed sync, storefront headers, and the limits that still surprise a large SKU shop. Adobe’s [Catalog Service for Adobe Commerce](https://experienceleague.adobe.com/en/docs/commerce/catalog-service/overview) page is the product definition I implement against. The service sits beside the application box. It keeps a dedicated index of product details, attributes, variants, prices and categories, then answers storefront reads from `https://catalog-service.adobe.io/graphql` in production, or the sandbox host while you test. Core `/graphql` stays the write path. Cart, checkout, customer and order mutations never move. I still treat native Magento catalog GraphQL as the fallback, not the PDP. Faceted URLs stay in [Magento faceted navigation and crawl budget](https://alanvo.com/blog/magento-faceted-navigation/). Live Search widgets already consume this same SaaS catalog. If search is in the same ticket, read [Adobe Commerce Live Search on production catalogues](https://alanvo.com/blog/adobe-commerce-live-search/) first. ## Why Adobe Commerce Catalog Service matters on a Magento catalogue Adobe Commerce Catalog Service matters on a Magento catalogue because it moves PDP, compare, carousel and category reads off the PHP request cycle and onto Adobe’s SaaS index. You stop asking the application to assemble a configurable product, its children, images, attributes and prices on every hit. You start treating catalog rendering as a feed job plus a storefront client that talks to a different host. What changed through 2025 and 2026 is that Catalog Service is no longer an optional extra next to Live Search. Adobe’s [Storefront Services GraphQL](https://developer.adobe.com/commerce/webapi/graphql/schema/storefront-services/) guide is explicit: Live Search and Product Recommendations require Catalog Service 2.2.0 or later to fetch complete product data. From Live Search 3.0.2 and Product Recommendations 3.0.2 the extension is bundled. The Product Details drop-in on an Edge Delivery storefront [requires Catalog Service](https://experienceleague.adobe.com/developer/commerce/storefront/get-started/architecture/commerce-services-and-backends/). The Product Discovery drop-in uses it for search results and category pages. Adobe’s storefront copy says those catalog reads can return up to ten times faster than routing every read through core GraphQL. That is a vendor figure. I do not invent a conversion lift from it. The other change is the product model. Catalog Service collapses Magento’s product types into two views. Simple, virtual, downloadable and gift card map to `SimpleProductView`. Configurable, bundle and grouped map to `ComplexProductView`. Prices on simples include regular and final amounts, with support for 16-digit values and four decimal places. Complex products do not have a single price. The service returns the linked simple prices, so a configurable shows a range until the shopper picks every required option. Personalized promotions are out of that calculation. If your PDP still expects a cart-rule price from a catalog query, this service will not give it to you. ![Adobe Commerce Catalog Service catalogue work on a large monitor](../../images/blog/adobe-commerce-catalog-service-1.jpg) Shopify and WooCommerce catalogues I ship do not have this split. Those platforms keep catalog reads on the application or on their own hosted APIs. Magento is the stack where a merchandiser can drown a PDP in attributes, then ask GraphQL to resolve them on every view. That is why I reach for Catalog Service on Adobe Commerce 2.4.4 and newer, and why I leave Magento Open Source on core GraphQL unless the merchant has a Commerce licence. ## How Adobe Commerce Catalog Service actually works Adobe Commerce Catalog Service actually works as the `magento/catalog-service` Composer metapackage, catalog feeds exported to Adobe SaaS, and a separate GraphQL schema that your storefront must call on purpose. Installing the module does not make Luma faster by itself. Adobe’s [onboarding and installation](https://experienceleague.adobe.com/en/docs/commerce/catalog-service/installation) steps (last update 20 August 2026) say you still have to update storefront code and route catalog queries through the gateway URL from onboarding. On Adobe Commerce on cloud or on premises you add the package from repo.magento.com, run `composer update "magento/catalog-service"`, then `setup:upgrade` on a self-hosted box, or push the lock file so cloud deploy applies it. If Live Search or Product Recommendations are already on, Catalog Service is installed or updated with those services. On Adobe Commerce as a Cloud Service the latest metapackage is already in the environment. You start from Adobe’s [Get Started with Catalog Service](https://experienceleague.adobe.com/en/docs/commerce/catalog-service/get-started) topic instead of Composer. API keys still come from the Commerce licence holder through the [Commerce Services Connector](https://experienceleague.adobe.com/en/docs/commerce/user-guides/integration-services/saas) (updated 20 August 2026). Production and sandbox key pairs identify SaaS data spaces, not your Magento environments. You paste both pairs once under System, Services, Commerce Services Connector, then pick the data space for that instance. Use the production data space only on production. Staging pointed at production mixes test URLs and live catalog data. Adobe then wants a support request to clean it up. [SaaS Data Export](https://experienceleague.adobe.com/en/docs/commerce/saas-data-export/overview) (updated 11 May 2026) is the pipe. It lands automatically when you add Catalog Service, Live Search, Product Recommendations or the Optimizer Connector. Catalog feeds cover products, attributes, prices, variations, categories and permissions. A scopes feed covers customer groups, websites, stores and store views. After the first full sync, cron keeps services current with partial updates and retries. I still confirm cron is running and that Catalog Attributes Feed, Product Feed, Product Overrides Feed and Product Variant Feed are set to Update by Schedule. ![Warehouse shelves standing in for a Magento inventory grid](../../images/blog/adobe-commerce-catalog-service-2.jpg) When I have to force a first sync from CLI, Adobe’s documented `saas:resync` order starts with scopes, then attributes, categories, products, prices, variants and product overrides. The first pass can take from a few minutes to several hours. Incremental edits after that are hash-based. Unchanged rows are skipped. `--cleanup-feed` is not a daily tool. Adobe warns that clearing local export state can leave deletions unsynced or stale SKUs in the remote index. On the storefront, Catalog Service queries do not use Magento’s `/graphql` URL. PaaS production is `https://catalog-service.adobe.io/graphql`. PaaS testing is `https://catalog-service-sandbox.adobe.io/graphql`. Adobe Commerce as a Cloud Service uses a tenant URL under `api.commerce.adobe.com`. Required headers are `Magento-Environment-Id`, `Magento-Store-Code`, `Magento-Store-View-Code`, `Magento-Website-Code`, `X-Api-Key`, and `Magento-Customer-Group` when prices are personalised by group. Firewalls must allow `commerce.adobe.io`. Load tests belong on sandbox. Adobe asks you to file a support ticket before you flood that host. The queries I actually wire are in Adobe’s [Retrieve catalog data with GraphQL](https://experienceleague.adobe.com/en/docs/commerce/catalog-service/graphql-queries) table. `products` takes SKUs and returns `ProductView` objects. Adobe’s [products query](https://developer.adobe.com/commerce/webapi/graphql/schema/catalog-service/queries/products/) page caps that at 100 SKUs per request. Use it for PDPs and compare. `refineProduct` narrows a complex product as the shopper picks options. `variants` returns every variation in one call so a PDP can show swatch images without a request per child. `categories` is the read-optimised tree for navigation, not the full Admin category model. `productSearch` is Live Search. It sits next to Catalog Service because the storefront uses both. Merchant attributes come back as `ProductViewAttribute` with storefront roles such as show on PDP, show on PLP, and show on search results. Images filter by `image`, `small_image` and `thumbnail`. Customisable input options sit in `inputOptions` with optional markup. That is the view model I map into a Hyva or headless PDP. I do not reuse core `Products` types. They are not interchangeable. API Mesh is optional. I add it when a storefront must stitch core mutations, Catalog Service reads and a third-party stock API behind one endpoint. Adobe Commerce Optimizer is a different platform with different headers (`AC-View-Id`). If a project has switched to the Optimizer Connector, I stop calling Catalog Service and I follow the Merchandising Services schema instead. ![Boxed products on a packing bench](../../images/blog/adobe-commerce-catalog-service-3.jpg) ## Production checklist before you point PDPs at the SaaS catalog A Magento store is ready for Catalog Service when the SaaS feed matches merchandising, storefront queries hit the services host, and core GraphQL is left for writes. 1. Confirm Adobe Commerce 2.4.4 or newer. This is not a Magento Open Source extra you drop onto a cheap VPS. 2. Read the [Catalog Service overview](https://experienceleague.adobe.com/en/docs/commerce/catalog-service/overview) and the [installation](https://experienceleague.adobe.com/en/docs/commerce/catalog-service/installation) page. If the merchant is on Adobe Commerce Optimizer, stop. That is a different API. 3. Install `magento/catalog-service` with Composer, or confirm Live Search or Product Recommendations already pulled it in. On cloud, commit `composer.lock`. 4. Connect Commerce Services API keys once. Scope the data space per environment. Production keys stay on production. 5. Set the catalog exporter indexers to Update by Schedule. Confirm cron. Open Data Feed Sync Status and the Data Management Dashboard before you touch the theme. 6. Run the first sync from the dashboard, or `saas:resync` in Adobe’s published feed order. Do not announce a PDP cutover while the product feed is still catching up. 7. Allowlist `commerce.adobe.io`. From staging, run a `products` query for a known simple SKU and a known configurable SKU with the correct store view and customer group headers. 8. Change the storefront. Point PDP, compare, carousel and (if you are not using Live Search widgets) category reads at the Catalog Service endpoint. Leave add-to-cart, coupon, customer and checkout on core `/graphql`. 9. Cap compare and carousel SKU lists at 100 per request. Batch above that. 10. Send `Magento-Customer-Group` on every catalog read that can show a logged-in price. A missing header is how B2B shared catalogs look cheap to a guest crawler and wrong to a signed-in buyer. 11. Keep promotions on the cart path. Catalog Service final price is discount-aware at the catalog level. It is not your full cart-rule engine. 12. If you use Hyva, confirm the GraphQL client can hold two endpoints and two header sets. A Luma theme that still calls core `products` has not adopted the service, even if Admin shows a green feed. 13. On Edge Delivery drop-ins, set `commerce-endpoint` to the Catalog Service URL and `commerce-core-endpoint` to Magento GraphQL, with the `cs` header block Adobe documents in storefront configuration. ![Watch product still used as a Magento PDP example](../../images/blog/adobe-commerce-catalog-service-4.jpg) 14. File a support ticket before sandbox load tests. Do not load-test production `catalog-service.adobe.io`. ## What breaks after you enable Adobe Commerce Catalog Service The first thing that breaks is a storefront that never changed. The extension can sync for a week while Luma or a custom theme still hits core `products`. Admin looks healthy. Shoppers see the same slow PDP. I treat “module installed” as incomplete until I can watch the browser call `catalog-service.adobe.io` on a product URL. The second break is header drift. Wrong `Magento-Store-View-Code` returns another website’s catalog. Wrong `Magento-Environment-Id` talks to a sleeping or empty data space. Wrong `X-Api-Key` pair (sandbox keys on a production space, or keys pasted from a database dump) fails after Admin encrypts them on save. Adobe is explicit: do not paste keys copied from a snapshot. Generate them from the licence owner’s API Portal and store the private key once. The third is stale feed after a catalog import. A merchant uploads thousands of simples, cron is late, and the PDP still shows yesterday’s price or a missing child. SaaS data is indexed asynchronously. Adobe’s storefront services guide says not to use this API when you need inventory or price guaranteed to the millisecond. I keep add-to-cart availability on a core or MSI check when a flash sale can sell out in seconds. The fourth is configurable shape. Catalog Service indexes parent and children, then `refineProduct` and `variants` expose the combination. A theme that still loops custom child collections from core GraphQL will double-fetch and can show a price that does not match the selected option. I delete that loop. I let `refineProduct` return the simple that the current option set points at. The fifth is SKU batching. Compare pages and merchandising widgets love to send 120 SKUs. The documented cap is 100. The query fails or truncates, and the rail looks randomly empty. I chunk. The sixth is SEO adjacency. Catalog Service can make a client-rendered PDP fast for shoppers and empty for Google if the HTML is a shell. I still want product name, price and primary image in the first HTML. Schema stays on the page I control. That work is in [Magento product schema for Google and AI search](https://alanvo.com/blog/magento-product-schema/), not in the SaaS index. The seventh is cleanup-feed used as a habit. A well-meaning `saas:resync --feed products --cleanup-feed` after a bad import can leave deleted SKUs alive in SaaS and hide new ones. I resync by SKU with `--by-ids` when a handful of products are wrong. I only clean the local feed table when support has cleaned the data space and we are rebuilding. ![Retail aisle used while thinking through Magento filters](../../images/blog/adobe-commerce-catalog-service-5.jpg) ## How to measure Adobe Commerce Catalog Service after go-live You measure Adobe Commerce Catalog Service with feed health, response time on the services host, and PDP fidelity against Admin, not with a homepage Lighthouse score. Adobe asks you to watch the Data Management Dashboard and Data Feed Sync Status. I add `var/log/saas-export.log` when a SKU is missing, and I run `saas:resync --feed products --dry-run --by-ids='SKU'` with `EXPORTER_EXTENDED_LOG=1` so I can read the payload without submitting it. I keep a list of about 20 SKUs the merchandiser cares about: a simple, a configurable with uneven child prices, a bundle, a grouped product, a gift card, a SKU with a custom option, a customer-group price, and a product that should be hidden from a shared catalog. I load each PDP logged out and logged in. I compare name, URL, image role, final price currency and `addToCartAllowed` to Admin. A large gap is a feed or header problem. I watch Core Web Vitals on product templates the same way I do after a Hyva move, which I wrote up in [Hyva theme and Magento Core Web Vitals](https://alanvo.com/blog/magento-hyva-core-web-vitals/). Catalog Service can shrink the GraphQL payload. It cannot fix an unoptimised gallery or a tag manager bundle. INP and LCP still need the theme work. Revenue is still gateway orders. I do not invent a conversion lift for a catalog-API ticket. On the [retail conversion Magento work](https://alanvo.com/work/retail-conversion/) the published figure is year-on-year sales, which mixed merchandising, UX and operations. Faster catalog reads made the PDP usable. They did not write the offer. Search Console still matters if category HTML is client-rendered from this API. I view-source a PDP and a category URL after cutover. I want product content in HTML, or a documented server render. ## Related Magento work on this site Catalogue reads are the same job I did when I directed ecommerce across [three Magento stores in the retail conversion work](https://alanvo.com/work/retail-conversion/), where year-on-year sales increased $2.5 million over three years. Shoppers had to open an appliance PDP without waiting on a heavy catalog query. I have also shipped Magento storefronts as contract work on an agency team, including the [Never Never Distillery Magento shop](https://alanvo.com/work/never-never-distillery/), where pack sizes and bottle variants have to resolve to one price after the shopper picks a size, and the [Arteriors Magento catalogue](https://alanvo.com/work/arteriors/), where lighting and furniture attributes are the PDP. Those builds are why I treat Catalog Service as a feed and a storefront client, not as a checkbox on a sales deck. ![Adobe Commerce Catalog Service catalogue work on a large monitor](../../images/blog/adobe-commerce-catalog-service-6.jpg) ## Adobe Commerce Catalog Service FAQ ### What does Adobe Commerce Catalog Service replace on Magento? Adobe Commerce Catalog Service replaces core GraphQL catalog reads for product detail, compare, carousels and, when you wire it, category navigation. It does not replace cart, checkout, customer accounts, orders, promotions that live on the quote, or Magento Admin. Live Search still owns on-site search. Catalog Service is the product data plane those widgets read. ### Can Adobe Commerce Catalog Service run without changing the theme? No. Adobe’s installation guide says you must integrate Catalog Service GraphQL queries into the frontend after the extension and the SaaS connection are in place. Live Search widgets and Edge Delivery drop-ins already know the endpoint. A Luma or Hyva theme that still calls Magento `/graphql` for `products` will not get the faster index. The feed can be perfect and the shopper still hits PHP. ### How long does Adobe Commerce Catalog Service take to sync? Adobe Commerce Catalog Service takes from a few minutes to several hours for the first catalog sync, depending on size. After that, cron sends partial updates. Adobe does not promise millisecond inventory. I do not announce a PDP cutover inside the first full sync, and I re-check a changed price after the next scheduled export rather than expecting the SaaS index to move with the Admin save. ### Does Adobe Commerce Catalog Service include personalized promotions? No. Adobe Commerce Catalog Service calculates regular and final catalog prices, including fixed product taxes, and it can honour customer group context through headers. Personalized promotions that apply on the cart are excluded. I keep those on core GraphQL when the shopper adds to cart. If a merchandiser expects a catalog query to show a cart-rule price, I show them the overview page and we move that rule to a place the quote actually evaluates. HTML version: https://alanvo.com/blog/adobe-commerce-catalog-service/