Where the PIM sits in a composable commerce stack

The move to composable commerce is common. One platform used to hold everything: frontend, catalog, checkout, CMS and search, bundled together and tightly coupled. That arrangement is being taken apart. Separate systems now handle each piece and talk to each other over APIs.

Picking Algolia for search and Stripe for payments splits the work across more systems. It doesn’t settle where product content lives, or who checks it before it goes out. Distributed isn’t the same as composable.

So the question is narrower than which tools you buy. A product value changes. What makes sure the storefront, the marketplaces, the AI agents and the recommendation engine all end up with that same value? And that someone checked it first?

Many teams never decide, so the work spreads across spreadsheets, one-off exports and whoever remembers. There is an answer, and it is the layer that is often under-specified or skipped: one system that holds the product record, checks it, and hands every other system its own version of it. Skip that layer and it costs you when a person shops. It costs you more when an AI assistant reads your catalog, because assistants may increasingly decide what gets found and bought.

The hard part isn’t choosing the tools.

Much writing on composable commerce stops at the shopping list. Which search engine, which CMS, which payment processor. Those choices matter less than what happens after you make them.

Here is what teams pick, and what they still have to solve.

The pattern repeats. Every row is the same problem in a different suit. One product record, many systems, each one wanting a different shape of it, and someone has to check the values before they go out.

Connectors move the data. They don’t decide what is correct.

What breaks.

Three arrangements keep failing in the same way.

Pattern 1. Product data stuck in the checkout system.

Product data lives in Shopify, commercetools or BigCommerce, because that is where the orders are. Those systems model a product for checkout first: SKU, price, inventory. Typed attributes and per-locale values, where they exist, aren’t built for enrichment, completeness or channel checks.

What breaks: a product family with 80+ typed attributes is hard to model and keep consistent there. Enrichment steps, completeness scoring and per-channel wording usually aren’t built in. Often, nothing keeps the product classification in one shape. Orders work. Everything downstream is fed scraps.

Pattern 2. Product data spread through the headless CMS.

Products sit in Contentful or Sanity next to the editorial content, because the team already works there. A CMS is built to move a page from draft to review to published. Product work is a longer chain: import, map, validate, enrich, score, approve, send, then watch what came back.

What breaks: supplier files have nowhere to land. Completeness per marketplace isn’t measured. Variants don’t inherit from a parent. Nothing holds the product classification in one shape. Channel-specific output isn’t generated. The records are stored. Nothing acts on them.

Pattern 3. Product context in pieces, everywhere.

A common one, and the hardest to untangle. Attributes in the ERP, descriptions in a spreadsheet, images in Google Drive, marketplace copy in a per-channel tool. Each system holds a piece. None of them holds the product.

What breaks: each channel shows something different, and often something wrong. Anyone can change anything, and nothing checks it. An AI assistant reading any one of those systems gets a partial product. Every new channel or market means arranging it all by hand again, so the time it takes to get live grows with each channel you add, instead of coming down as the setup matures.

Where PIM fits.

Shopping for a PIM as a place to put things is 2015 thinking. A PIM keeps one record per product. The work sits around that record: the values people fill in, the checks before publishing, and the file each retailer wants.

The two framings ask for different software, and one question tells you which one you bought. Ask your PIM whether a product is ready for a given channel. A store answers by showing you the record. The other can tell you what that channel still needs.

The PIM sits in the middle of the product flow. Everything arrives from a source system, should get checked there, and leaves in the shape the receiving system asked for. The table below takes each direction in turn and says what a PIM can do with it.

Read down the last column. That is the job a PIM does: take a supplier’s row and turn it into something a marketplace will accept and an AI assistant can read. It keeps doing that, with review where it matters.

AI assistants raise the bar.

This isn’t a matter of taste. When an assistant reads your catalog instead of a person, what the catalog has to hold changes.

An assistant can’t recommend a product whose attributes are empty. It can’t buy one whose availability is out of date. It can’t vouch for a record when nothing shows who approved the values. That is the difference between being in the answer and being left out of it.

Scattered product content was expensive before. Now it can decide whether you appear.

Situations you will recognize.

Two of them, side by side.

What to require of a PIM.

Not every PIM can do this work. The requirements below are specific.

CataZenta publishes Approved products to Amazon and Shopify after checking each against that channel’s rules, builds CSV or Excel feeds from other channels’ templates, and lets developers run imports, exports and publishing through a REST API, tracked as jobs. It has no ERP connectors or ACP/UCP endpoint, doesn’t run its range and format checks on imports, and doesn’t notify your systems when a job finishes.