Skip to main content

Product Sharing

Product sharing allows one Mimeeq account (the owner) to make their products available to other accounts (partners). Partners embed and sell the owner's products on their own websites, while the owner retains control over the product definition — options, 3D models, rules, and pricing structure.

From an integration perspective, shared products behave like normal products in embeds and API responses. The key differences are where the data comes from, what can be customized locally, and how chain validation determines whether the product loads at all.

How Sharing Works​

A shared product is a lightweight reference that points to a source product owned by another customer. The configurator resolves this reference at runtime, merging source product data with the partner's local overrides to produce what the end user sees.

Sharing can be multi-level — a partner can re-share a product to another partner, creating a chain:

Partner C (your embed)
  └── shared from Partner B
        └── shared from Owner A (source product)

Every link in this chain is validated on every request. There is no caching for shared products — the system always evaluates the current state of the entire chain. This means changes to status, privacy, licence limits, or access assignments take effect immediately.

What the End User Sees​

End users don't know or care that a product is shared. The configurator loads, options work, prices display, and add-to-cart fires the same events with the same payload structure. The FinishEventPayload from a shared product is identical to one from an owned product.

The only observable difference is in the product metadata accessible through observers — shared products carry additional fields that identify their origin.

Data Ownership: Source vs. Local​

When a shared product loads, the configurator merges data from two sources. Understanding which data comes from where matters when debugging unexpected behavior or building custom UIs.

From the source product (owner)​

The owner controls the core product definition. These cannot be changed by the partner:

  • Configuration options, option sets, and material collections
  • 3D meshes, models, materials, and scene setup
  • 2D image layers and views
  • Business logic rules (triggers, actions, conditions)
  • Widget types and group styling
  • SKU code structure
  • Modular settings (snap points, connections, component definitions)
  • Base pricing structure
note

For shared products, filter definitions (used by the Filter widget) come from the source product's data rather than from the partner's customer configuration. This ensures filter categories and attributes match the source product's option sets.

From the local product (partner)​

The partner can customize these fields locally:

  • Product name and display name
  • Product code (prefix)
  • Description
  • Manufacturer, designer, and collection metadata
  • Product categories and product groups
  • Default configuration code
  • Preview image (thumbnail)
  • Tabs (if override is enabled — see Sharing Overrides)
  • Delivery information (if override is enabled)
  • Related products
  • BOM (Bill of Materials) and bundle settings

Computed at runtime​

These fields are resolved during chain validation:

  • disabled — whether the chain is valid and the product can load
  • sharingCustomerIds — array of all customer IDs in the chain
  • owner — name of the immediate parent customer
  • ownerCode — product code of the immediate parent product
  • rootCustomerDefaultLang — default language of the source owner

Sharing Modular and Hybrid Modular Products​

When you share a modular or hybrid modular product, only the main product is shared explicitly. All components used within it — whether they're Component-type products or standard products acting as components — are resolved from the original owner's account automatically. The partner receives the complete assembly as-is.

This means partners cannot add, remove, or rename components within a shared modular product. The component list, snap point definitions, connection rules, and spatial relationships all come from the source owner. The partner's local overrides (name, description, categories, etc.) apply only to the main product entry, not to individual components.

If the source owner adds or removes components from the modular product, those changes appear for all partners immediately — the same runtime resolution that governs the sharing chain also applies to component loading.

Performance Considerations​

Shared products are inherently slower to load than owned products. This is because:

  • No read model caching. Owned products that are Active and Public get a pre-built JSON read model served from CDN. Shared products always generate an empty read model and resolve all data from the API at runtime.
  • Chain validation overhead. Every link in the sharing chain is validated on every request — customer status, product status, licence limits, company/product group assignments. Longer chains mean more validation steps.

For most integrations this difference is negligible, but it's worth knowing if you're embedding many shared products on a single page or if load time is critical. Shorter sharing chains perform better than deep multi-level chains.

Sharing Overrides​

Partners can optionally override specific content from the source product. These are controlled by sharingSettings on the product:

Tabs override (overrideTabs) — When enabled, the partner's own tabs replace the source product's tabs. This lets partners customize the information panels (downloads, materials, descriptions) shown alongside the configurator without affecting the source product.

Delivery override (overrideDelivery) — When enabled, the partner's delivery time settings replace the source product's. Item Master-based delivery is disabled when this override is active.

In multi-level chains, the first product in the chain (walking from the embedding partner toward the source) with an override flag enabled wins. If nobody in the chain enables an override, the source product's data is used.

Chain Validation and the disabled Flag​

The disabled flag is the gatekeeper for shared products. It determines whether the embed renders or shows nothing. The chain is validated link by link from the embedding partner's product up to the source. If any link fails validation, the entire product is disabled — there's no partial resolution.

What breaks a chain​

At each link in the chain, the product is disabled if any of these conditions are true:

  • The parent product is Inactive (status ≠ ACTIVE)
  • The parent product is Private (visibility = PRIVATE)
  • The parent product is a Component (not independently loadable)
  • The parent customer account is not active
  • The partner doesn't have an active company linked to the parent customer
  • The partner's company isn't assigned to a shared product group containing the parent product

Additionally, after the full chain is walked, licence limits are checked for every customer in the chain. The source owner must have sharing and product hosting enabled; every intermediate partner must have shared product access enabled.

warning

Chain validation is all-or-nothing. One broken link — anywhere in the chain — disables the product for the embedding partner. If a shared product suddenly stops loading, check the entire chain for status, privacy, or access changes.

What this means for embeds​

A disabled shared product behaves exactly like an inactive local product. The mmq-embed element renders nothing — no error, no event, just empty space. If you're building error handling around embed loading, the mimeeq-app-loaded event will still fire (it indicates the library loaded), but no product will render.

Because validation runs on every request with no caching, changes are immediate:

  • Owner deactivates the source product → all partner embeds go dark instantly
  • Owner sets the source product to Private → same result
  • Admin restores the product to Active + Public → partner embeds start working again immediately

Translations and Language Handling​

Shared products introduce a language fallback chain. The source product may support different languages than the partner's account.

When the configurator resolves translations for a shared product:

  1. If the source product has a translation in the requested language, it's used
  2. If not, the system falls back to the source owner's default language (rootCustomerDefaultLang)

This means partners always get usable translations, even if the source owner doesn't support all of the partner's configured languages. The partner's local overrides (product name, description, etc.) use the partner's own translations.

Detecting Shared Products​

The product data exposed through observers (mainProductData) does not include sharing-specific fields like product type, owner name, or chain information. Shared products are intentionally transparent — they present the same data shape as owned products.

This means your integration code doesn't need to handle shared products differently. Event payloads, pricing, option structures, and cart integration all work identically regardless of whether a product is shared or owned.

If a shared product stops loading unexpectedly, the cause is almost always a chain validation failure — check with the product owner for status, privacy, or access changes upstream.

Effect on Visibility Controls​

Shared products inherit visibility constraints from every product in the chain. The partner's own Status, Privacy, and Visibility settings apply on top of the chain validation:

  • A partner can set their local copy to Inactive — this hides it without affecting other partners
  • A partner can set their local copy to Private or Restricted — this limits access on their site
  • But a partner cannot make a product more accessible than the chain allows. If the source is Private, no local setting can make it visible.

The Visible in Menu flag works locally — partners control whether a shared product appears in their own product lists independently of the source owner's setting.

Next Steps​

For admin setup instructions, see Sharing Mechanism for Products Owner and Sharing Mechanism for Partners on the help site.