Headless and Composable Commerce for Aftermarket Catalogs

Web Shop Manager 6.0 is a headless, API-first commerce platform for fitment-driven aftermarket catalogs. The storefront is a Next.js application, the commerce core is Saleor exposed over GraphQL, vehicle search and Year/Make/Model fitment run natively through PartsLogic, and ACES and PIES supplier data is ingested and mapped as a managed service. For merchants whose catalogs are navigated by vehicle rather than by category alone, Web Shop Manager is an alternative to commercetools, Elastic Path, BigCommerce, Adobe Commerce (Magento), and Shopify: the same headless and composable architecture, with the fitment layer already built, connected, and operated instead of assembled from separate vendors.

Why headless and composable get harder when fitment drives the catalog

A brake and chassis distributor writes the RFP that has become standard: headless storefront, composable back end, API-first, no monolith. Three vendors demo well. Then somebody asks what happens when a customer types “2019 Ram 3500 front brake pads,” and the catalog has to know that the single-rear-wheel truck and the dually can take different components, and that the brake package and drivetrain may change the answer again. On a generic composable stack the answer is a statement of work: build a fitment service, model ACES applications inside it, wire it into search, wire it into the product page, wire it into the cart, and keep it synchronized every time a supplier ships a new PIES file.

That is the real shape of the decision. Composable vendors are good at commerce primitives: catalog, pricing, promotions, checkout, order orchestration. None of those primitives include a vehicle. In an apparel catalog that does not matter. In an aftermarket catalog the vehicle is the key that shoppers navigate by, and most of the pieces you were told you could compose later turn out to depend on it.

• Fitment is a relationship, not an attribute: one part number can map to thousands of year, make, model, submodel, and engine applications, each carrying its own qualifiers
• Data arrives continuously: ACES application data and PIES product data come on different cadences from different suppliers, so ingestion is an ongoing operational workflow rather than a one-time import
• Vehicle context spans the journey: search, browse, the product page, the cart, and the returns workflow all need the same vehicle context, which makes fitment a first-class part of the composition instead of a front-end widget
• Kits multiply the problem: a lift kit fits a truck only if every component in the kit fits that truck
• Machines need it too: structured data for crawlers and answer engines has to carry the vehicle relationship, and a relationship that exists only inside a browser filter is invisible outside the browser

What a composable stack actually has to compose in an aftermarket catalog

Before comparing vendors it helps to write down the components a fitment-driven storefront needs, because that list is what the word composable has to cover. Most platform evaluations score the commerce core carefully and skip the layer that decides whether a customer buys the right part.

• Vehicle taxonomy service: resolves year, make, model, submodel, engine, and drivetrain, and answers “does this part fit this vehicle” as an API call rather than as a page filter
• ACES ingestion: maps supplier application data onto that taxonomy. ACES is the Auto Care Association standard for vehicle applications, and it references the VCdb vehicle database, the PCdb product-classification database, and the Qdb qualifier database. Qualifiers are the part that gets flattened into free text when the pipeline is improvised
• PIES ingestion: handles product attributes, digital assets, packaging, and interchange data, on its own cadence from its own set of suppliers
• Fitment-aware search: a vehicle selection narrows results server side, and a zero-result query can fall back to compatible alternatives instead of an empty page
• Storefront state: vehicle context survives navigation rather than resetting on each page
• Structured-data output: compatibility is exposed to crawlers and answer engines, so the fitment answer exists outside the rendered page
• Operations layer: supplier feeds, tiered pricing, dealer accounts, and ERP synchronization, since most aftermarket merchants run B2B and B2C from the same catalog

The question is not whether those pieces can be built on a modern API-first platform. The question a merchant is actually asking when they search for a headless platform that supports fitment and ACES/PIES is which of them arrive already built, already connected, and already operated by somebody else.

Where generic composable platforms leave the fitment layer to you

The strongest composable vendors are strong for good reasons. commercetools built a clean, well-documented API-first commerce core with a real partner ecosystem. Elastic Path has deep experience with configurable products and complex B2B catalogs. BigCommerce ships a capable managed platform with a supported headless storefront path. Adobe Commerce (Magento) and Shopify both support headless front ends and carry the largest app ecosystems in commerce. None of that is in dispute.

What is worth being precise about is where the aftermarket-specific layer comes from on each path. On a generic composable stack the vehicle taxonomy, the ACES and PIES pipelines, the fitment-aware search behavior, and the vehicle-context handling in the storefront are assembled from third-party services, custom microservices, or an integration partner. That is a build, an ongoing maintenance commitment, and a set of interfaces the merchant owns permanently.

The useful comparison is less about whether a composable vendor can support fitment and more about whether the fitment model, the ACES and PIES workflows, and the search behavior come from the same platform that runs the catalog. Compare the platforms on the specific workflows aftermarket merchants run.

How Web Shop Manager 6.0 is architected

The pieces are worth naming plainly instead of describing in category language. The storefront is a Next.js application deployed on Vercel. The commerce core is Saleor, exposed through a GraphQL API. Search and fitment run as PartsLogic, a separate service that Web Shop Manager builds and operates. Web Shop Manager has been building aftermarket commerce for more than 25 years, and stores on the platform have processed over $400 million in online sales.

• Decoupled storefront: a Next.js front end talks to the Saleor GraphQL commerce core over an API, so storefront work and commerce work can ship independently
• Incremental static regeneration: product and category pages can be pre-rendered and revalidated on demand, which is how a storefront stays fast on a catalog with a large number of vehicle-and-part combinations
• Per-tenant isolation with a shared core: storefront features live in a shared core, and each tenant pins and deploys its own build of that core, so improvements are adopted per store rather than pushed simultaneously and one merchant’s release is not in another merchant’s path
• One integration surface: the commerce core and the search-and-fitment service each expose documented service APIs, presented to merchants and their developers as a single integration surface for product, fitment, kit, and inventory data
• PartsLogic as a first-class service: fitment-aware search and Year/Make/Model lookup are part of the platform rather than an app the merchant sources separately
• ACES and PIES workflows: ACES and PIES application and product data can be ingested and mapped onto the catalog through Data Services & Standards workflows, with cadence and source configurable per supplier
• Operated, not assembled: Web Shop Manager runs the infrastructure, the release pipeline, and the integration layer against a 99.95% uptime standard, so merchants can run the architecture without staffing a dedicated platform team
• Performance held at launch: storefronts are gated at a 90 or better mobile PageSpeed score before they go live, which is a policy rather than an aspiration

If MACH is the vocabulary your evaluation committee uses, the mapping is straightforward: the storefront is decoupled from the commerce engine, the commerce core and the search-and-fitment service are separate services with their own APIs, the API is the primary interface rather than a side door, and the whole thing runs as a managed cloud deployment. Web Shop Manager is not a MACH Alliance member and does not present itself as one, so read that as a description of the architecture rather than a certification. The deeper platform detail lives on Headless / API-First Commerce, and the Saleor layer is documented across the Saleor Integrations cluster.

Built for aftermarket, adaptable to adjacent technical markets

The architecture took this shape because of automotive aftermarket requirements, where a single brake rotor listing can carry many qualifier combinations across year range, engine displacement, drivetrain, brake-package level, and rotor diameter before the platform can confirm it fits. The same pattern of structured attributes, enforced dependencies, and guided narrowing appears in adjacent technical markets. The field labels change; the underlying problem does not.

Truck accessories: running boards and step bars may vary by cab configuration and drivetrain, and mounting hardware can differ with ride height. A storefront that loses vehicle context between the search result and the product page produces a confident add-to-cart and a return.

Diesel performance: emissions and cooling components frequently change mid-generation, so two model years of the same engine family may not be interchangeable. That distinction lives in ACES qualifier data, which means the API serving the storefront has to carry qualifiers, not just a year range.

Off-road: skid plates and armor may vary by submodel and trim even within the same model year. Submodel-level resolution has to survive the trip from the search service through the commerce API to the rendered page.

Powersports: drive belts and clutch components can differ between turbo and non-turbo variants of the same machine, sometimes by a single digit in the part number. Machine model plus engine is the same taxonomy shape as vehicle submodel filtering, with different labels.

The same architecture pattern applies in truck accessories, diesel performance, off-road, powersports, appliance parts, industrial / MRO, heavy equipment / ag / construction parts, trade supply, medical / lab supply, and other technical eCommerce markets.

Headless architecture is part of a larger AI-ready commerce strategy

Architecture and AI readiness are increasingly evaluated together. Answer engines consume rendered pages, feeds, and structured markup today, so the immediate work is making compatibility visible in all three. As agent-assisted buying grows, a documented API and a structured catalog are what make programmatic access reliable rather than best-effort. That is why AI-ready commerce and headless architecture belong in the same evaluation.

An API-first foundation is what makes programmatic access possible, and structured fitment data is what makes the answer correct. A platform can have one without the other, and both failure modes are visible: an open API over a flat catalog can return confident but wrong compatibility answers, while excellent fitment data locked behind a rendered page cannot be reached at all. The stronger position is both. That is the connection between this page and Preparing for Agent-Assisted Buying, which covers the transaction side of the same problem. The data side is covered in AI Fitment and Compatibility Guidance.

Practically, the readiness requirements are the same components listed earlier in this page, viewed from the machine’s side: a documented API a machine can query without a browser, sitting on top of catalog data that already carries the vehicle relationship and stays current as suppliers change it.

Headless and composable readiness checklist

Use this before signing a composable platform contract. Each line is a question with a verifiable answer, and the answers tend to differ from what the architecture diagram implies.

Architecture

• Is the storefront genuinely decoupled from the commerce engine, and can each deploy without the other?
• Is there one integration surface for product, fitment, kit, and inventory data, or several partial ones?
• Is the search-and-fitment layer a service with its own API, or a front-end component?
• Who operates the infrastructure and the release pipeline after launch, and is that cost in the quote?

Fitment and data standards

• Does the platform hold a vehicle taxonomy natively, or does fitment come from a separate vendor?
• Can ACES application data be ingested with VCdb, PCdb, and Qdb qualifiers intact, rather than flattened into text?
• Can PIES product data, assets, and interchange data be ingested on a per-supplier cadence?
• What happens to fitment when the commerce core is upgraded?

Discovery and storefront

• Does a vehicle selection narrow results server side, and does the context survive navigation into the product page and the cart?
• Do zero-result vehicle queries fall back to compatible alternatives instead of an empty page?
• Are category and product pages pre-rendered and revalidated, and what mobile PageSpeed score does the vendor commit to at launch? Web Shop Manager gates storefronts at 90 or better on mobile before they go live.
• Is compatibility exposed in structured data and feeds, not only in the rendered page?

Operations and governance

• Can the same catalog serve B2B pricing tiers, dealer accounts, and B2C shoppers?
• How do supplier feeds, ERP synchronization, tax, shipping, and fraud tooling connect, and who maintains those connections?
• Is each store isolated from the others at the deployment level?
• How do platform improvements reach an individual store after launch, and does the store control when it adopts them?

If most of those answers come back as “that is a services engagement,” the composable platform is real and the aftermarket layer is the project. Request a demo and walk this checklist against your own catalog.

Build a fitment-aware headless architecture

If your evaluation started with headless and composable and ran into fitment, ACES, and PIES, those two requirements are not in tension. They rarely arrive from the same platform. Web Shop Manager 6.0 runs a Next.js storefront against a Saleor GraphQL core with PartsLogic handling search and fitment, delivered as a managed platform rather than an integration program, with a 4.98 out of 5.0 client satisfaction rating across 25 years of aftermarket builds. Talk to a specialist about the architecture your catalog actually requires.