Multi-Tenancy

What it solves

Most organizations do not operate a single catalog for a single market. They manage multiple product lines, brands, or regional experiences — each with different products, business rules, users, and merchandising strategies.

Without multi-tenancy, each environment would require a separate platform deployment, increasing infrastructure costs, maintenance overhead, and operational complexity.

MXP multi-tenancy allows multiple fully isolated environments — called tenants — to run within a single MXP deployment. Each tenant has its own catalog, users, configurations, enrichment pipelines, discovery rules, and analytics.

The infrastructure is shared. The data and operational context are not.

When to use it

Multi-tenancy is designed for organizations that need operational separation without maintaining multiple independent platform deployments.

Separate business units

Organizations with unrelated product catalogs can operate each business unit independently within the same MXP deployment.

Examples include:

• Consumer electronics
• Industrial equipment
• Automotive products

Each tenant can maintain:

• Independent catalogs
• Separate taxonomies
• Custom enrichment logic
• Dedicated merchandising rules
• Isolated user access

Regional catalogs

Global organizations can create region-specific tenants to support localized commerce experiences.

Each regional tenant can define:

• Language
• Currency
• Product assortment
• Search and discovery behavior
• Compliance rules

Example tenant IDs:

• vortex_us
• vortex_uk
• vortex_jp

Brand separation

Companies managing multiple brands can isolate each brand experience while centralizing platform operations.

Each brand can maintain:

• Separate discovery experiences
• Dedicated merchandising teams
• Independent analytics
• Distinct business rules

Environment isolation

Tenants can also be used to separate operational environments such as:

• Production
• Staging
• QA
• Internal testing

This allows teams to validate configuration changes safely without affecting production traffic.

Key concepts

Tenant — a fully isolated environment within MXP. Each tenant contains its own:

• Product catalog
• Enrichment configurations
• Discovery rules
• Recommendation models
• Analytics and reporting
• User roster and permissions

No data crosses tenant boundaries.

Tenant ID — a unique identifier for a tenant within MXP APIs and configuration.

Examples:

• zyndra_music
• zyndra_bikes
• vortex_us

Tenant IDs are commonly used in:

• API requests
• Authentication context
• Data ingestion configuration
• Routing and indexing operations

User scope — user access is managed independently for each tenant. The same user can have different roles across tenants:

• Administrator in one tenant
• Editor in another
• Viewer in a third

Permissions and visibility are always scoped to the currently active tenant. See User Management for more information.

How it works

When a user logs into MXP, they enter a specific tenant context. All visible data and configuration are scoped exclusively to that tenant. This includes:

• Catalog data
• Discovery rules
• Enrichment settings
• Analytics and metrics
• User permissions

If a user has access to multiple tenants, switching tenants changes the entire working environment, including catalogs, rules, configurations, and team access.

Under the hood, tenants share the same platform infrastructure and services, but all tenant data is logically partitioned into isolated namespaces. Shared compute and indexing resources are used efficiently while maintaining strict separation between tenants.

Quick example

Zyndra operates two independent business units within the same MXP deployment.

zyndra_bikes manages Zyndra's motorcycle catalog, including:

• Vehicle categories
• Engine specifications
• Riding-style attributes
• Seasonal merchandising campaigns

The tenant is operated by a dedicated powersports merchandising team.

zyndra_music manages Zyndra's musical instruments catalog, including:

• Instrument taxonomy
• Skill-level enrichment
• Audio-specific attributes
• Music-focused discovery rules

This tenant has a completely separate user group with no visibility into the motorcycle catalog.

Result — both tenants operate within the same MXP deployment while remaining fully isolated from one another.

Related pages

• User Management — manage roles and permissions per tenant
• Attribute Enrichment — enrichment pipelines are configured per tenant
• Discovery Rules — discovery rules apply only within their tenant
• Navigating the Platform — switch tenants from the top-right tenant selector