B2C Commerce Multi-Site: Catalog and Inventory Sharing

A retail brand operates three storefronts: a domestic consumer site, a regional consumer site covering nearby markets, and a B2B portal for wholesale buyers. Each needs its own pricing, currency, locale, and customer experience. The brand also wants to share the product catalog as much as possible so adding a new SKU happens in one place, not three.

The decisions about how to share catalog data, inventory pools, content libraries, and customer accounts decide whether the architecture scales cleanly to a fourth or fifth site or fragments under the load of duplicated data. Sapota's Salesforce team has shipped multi-site B2C Commerce realms across retail, fashion, and B2B distribution, and the pattern that holds up is consistent.

The B2C Commerce sharing model

The platform exposes several shareable resources, each with its own assignment rules:

Resource	Sharing scope
Master catalog	Shared across all sites within the same realm
Storefront catalog	Per site (each site picks one storefront catalog)
Inventory list	Per site (each site picks one inventory list)
Customer list	Per site or shared (configurable)
Library (content)	Shared across all sites in the realm
Price book	Per site
Promotion campaign	Per site

Master catalogs hold the canonical product definitions: name, attributes, images, related items. Storefront catalogs filter and organize master catalog products into site-specific category trees. Inventory lists hold quantity-on-hand data. Each site picks one storefront catalog and one inventory list.

This separation lets a single master catalog feed multiple storefronts with different category structures, different inventory pools, and different commercial rules.

A typical multi-site architecture

For the three-site brand above:

Realm: brand-retail-realm
  Master Catalog: brand_master
    20,000 SKUs across apparel, accessories, footwear

  Storefront Catalogs:
    - storefront_domestic_b2c   (filtered to domestic-relevant SKUs)
    - storefront_regional_b2c   (filtered to regional + domestic SKUs)
    - storefront_b2b            (filtered to wholesale-eligible SKUs)

  Inventory Lists:
    - inventory_domestic_warehouse
    - inventory_regional_warehouse
    - inventory_b2b_pool

  Sites:
    - site_domestic_b2c (storefront_domestic_b2c + inventory_domestic_warehouse)
    - site_regional_b2c (storefront_regional_b2c + inventory_regional_warehouse)
    - site_b2b          (storefront_b2b + inventory_b2b_pool)

  Library: shared_brand_library
    Hero banners, brand assets, policy pages shared across all sites

One product definition. Three storefronts. Three inventory pools. Shared brand content. Each site can have its own pricing and promotions independent of the others.

When to share vs split master catalogs

The temptation is to share one master catalog across the realm. The platform supports this and it works for most cases. The exceptions:

Split master catalog when the brands are genuinely separate. A holding company running an electronics retailer and a furniture retailer. The product attributes, taxonomy, and lifecycle differ. Sharing a master catalog forces compromises that hurt both businesses. Use two master catalogs.

Split when product attribute definitions diverge. B2C consumer products use one set of attributes (color, size, lifestyle). B2B distribution products use another (case pack, MOQ, lead time). Forcing both into one master catalog clutters the schema. Two masters; explicit overlap where products genuinely cross over.

Share when the brands are facets of the same business. Domestic and regional consumer sites selling the same brand. Same products, different geo-pricing. Share the master, use storefront catalogs to scope availability.

Default to sharing; split only with documented justification.

Storefront catalog organization

A storefront catalog is the site's category tree built from master catalog products. Two patterns:

Mirror the master. The storefront catalog re-creates the master's category structure with site-specific naming and language. Simple, easy to maintain, but loses site-specific merchandising opportunities.

Re-organize per site. The storefront catalog creates a different category tree tuned for the site's audience. Same products, different placement. More merchandising flexibility, more authoring burden.

Most consumer sites use a hybrid: the top-level structure mirrors the master with site-specific naming, while featured collections and seasonal categories are site-specific.

Inventory list assignment

Inventory drives availability. A site without inventory data shows products as out-of-stock or hides them entirely. The assignment is one inventory list per site.

Decisions that recur:

One pool per warehouse vs aggregated pools. A site shipping from a single warehouse maps cleanly to that warehouse's inventory list. A site shipping from multiple warehouses needs an aggregation: either a virtual inventory list summing the others, or per-warehouse logic in the cart and checkout flow.

Inventory sync cadence. Real-time sync via OCAPI or webhook works for low-volume sites. High-volume sites need batched updates with optimistic concurrency control (the site shows yesterday's stock; the checkout step verifies real-time).

Safety stock. Most retailers reserve buffer inventory for fulfillment edge cases. Configure as inventory list attributes rather than reducing the on-hand value directly; preserves the audit trail.

Customer list strategy

Customer lists hold customer accounts and their authentication. Two assignment patterns:

Per-site customer list. Each site has its own customer list. A user with an account on the domestic site is not the same user on the regional site. Clean separation, but the user has to re-register if they switch sites.

Shared customer list. Multiple sites point to the same customer list. The user logs in once and is recognized on all participating sites. Better cross-site experience but harder to maintain per-site customer attributes (preferences, marketing consents, regional regulations).

For brands operating consumer sites in the same broad market, shared customer list is usually right. For sites with genuinely different audiences (consumer vs B2B), separate lists. For sites with regulatory differences (GDPR-region vs not), separate lists.

Library sharing

The content library holds content assets, content slots, and folders. The platform supports library sharing across sites within a realm. Three patterns:

Single shared library. All sites point to the same library. Hero banners, policy pages, brand guidelines defined once. Site-specific content lives in slots that reference shared assets with site-specific configuration. Simplest model.

Per-site library. Each site has its own library. No content reuse. High authoring burden. Reserved for truly independent brands.

Hybrid (shared base library + per-site libraries). A shared "brand" library holds reusable assets. Each site has its own library for site-specific content. The cartridge path includes both libraries; site-specific overrides win when both define an asset.

For Sapota's standard multi-site engagements, the hybrid pattern handles most cases. Shared base library for brand assets, per-site library for site-specific merchandising.

Common multi-site mistakes

Five patterns Sapota has seen on engagements:

1. Master catalog fragmentation under "site-specific" excuses. Three sites end up with three master catalogs because the team needed "different attributes per site." Six months later, a product change requires three edits. Use storefront catalogs to scope, not master catalogs.

2. Inventory lists configured wrong. A new site goes live pointing at the wrong inventory list. Stock data displays incorrectly. Verify the assignment in Business Manager before launch.

3. Shared customer list across regulatory boundaries. A site in a strict-privacy jurisdiction shares customer list with a permissive jurisdiction. Compliance issue. Separate the lists.

4. Library sharing breaking site themes. A content asset edit on the shared library propagates to all sites unexpectedly. Audit which assets are intentionally shared vs accidentally; use per-site libraries for site-specific concerns.

5. Promotion campaigns assumed to share. A team configures a promotion on one site and expects it to apply on a sister site. Promotions are per-site. Re-create on each site as needed, or use a configuration-as-code approach to define once and deploy across.

What good multi-site architecture looks like

A B2C Commerce realm running multi-site cleanly:

• One master catalog per genuinely separate brand (most cases: one realm-wide master).
• Storefront catalogs scope per site without duplicating product definitions.
• Inventory lists match warehouse and fulfillment reality.
• Customer lists shared when the audiences overlap, separate when they do not.
• Library shared as a brand foundation with per-site overrides for site-specific concerns.
• Configuration as code or documented in a runbook; nothing depends on Business Manager UI memory.

Sapota's Salesforce team has shipped multi-site B2C Commerce realms across retail, fashion, and B2B distribution, including realm restructures inherited from previous partners. Multi-site looks similar to multi-tenant from far away; up close, the sharing decisions determine whether the architecture scales.

---

Designing or auditing a multi-site B2C Commerce architecture? Sapota's Salesforce team, certified on B2C Commerce Developer (Comm-Dev-101), handles realm structure, catalog organization, and inventory strategy on production engagements. Get in touch ->

See our full platform services for the stack we cover.