/rp-mapper

Wix Business Solutions Taxonomy For rp-mapper

This file is a curated, mapper-oriented taxonomy of Wix business solutions and their primary entities.

Use it during rp-mapper to:

• classify each discovered source entity into a likely Wix solution area
• distinguish native Wix targets from data that requires custom collections
• keep mappings explicit and consistent across migration projects

This is intentionally curated, not exhaustive. Prefer stable, first-party solutions and stable entity families that are relevant for migration planning.

Primary source docs

• About Wix APIs
• Integrating with Wix's Business Solutions
• Business Solutions | Wix Studio

Critical distinction: eCommerce vs Stores

This distinction must stay explicit in mapper output.

Wix eCommerce

Wix eCommerce is the shared commerce platform layer. It owns the purchase flow and operational commerce entities that are reused across multiple vertical apps.

Typical eCommerce entities:

• carts (the unified cart + checkout entity)
• orders
• order billing / refunds
• payment and fulfillment state tied to orders

Use eCommerce when the source data is about:

• cart contents
• checkout state
• order lifecycle
• fulfillment and payment operations
• cross-vertical commerce operations that are not specific to a single catalog app

Wix Stores

Wix Stores is a vertical app built on top of the commerce platform. It owns the product catalog and store-specific merchandising model.

Typical Stores entities:

• products
• categories / collections
• variants
• inventory items
• store inventory locations

Use Stores when the source data is about:

• product catalog structure
• product options and merchandising
• stock and inventory allocation
• store-specific catalog metadata

Other vertical apps

Other business apps also sit above shared platform layers and bring their own domain model:

• Bookings: services, staff, resources, schedules, bookings
• Events: events, ticket definitions, tickets, RSVPs, guests
• Restaurants: menus, sections, items, modifiers, reservation locations, reservations
• Pricing Plans: plans and plan orders / subscriptions

If the source platform mixes these layers together, separate them in the mapping plan instead of collapsing them into one Wix target.

Solution index

ecommerce

Main page:

• Integrating with Wix's Business Solutions

Short description:

• Shared commerce platform for purchase flow and order operations. It is the canonical target for carts (Cart V2, which now also covers checkout) and orders, even when catalog data originates in a vertical app such as Stores or Bookings.

Primary entities:

Mapper notes:

• A source system's separate "checkout" has no distinct Wix target. The cart is the unified purchase-flow entity (there's no separate checkout), so map a source checkout's input state onto cart: billing → paymentInfo.billingAddress, shipping/delivery → deliveryInfo, applied coupons → cart coupons. Calculated price and payment figures are NOT stored on the cart — both the price totals (summary.priceSummary) and the payment breakdown (summary.paymentSummary — amount due, gift-card deductions, and the like) are computed on demand by Calculate/Estimate Cart (returned in a CartSummary), and the final figures live on the order after placement — so don't try to persist a source checkout's computed totals on the cart.
• If the source platform exposes products and orders in one model, split catalog entities into the vertical app and transaction entities into ecommerce.
• If the source has historical orders but no cart or checkout history, map directly to order and document missing pre-purchase state.

stores

Main page:

• About the Wix Stores Catalog API

Short description:

• Vertical commerce app for managing a store catalog, merchandising structure, variants, and inventory. Stores sits above the shared eCommerce purchase flow.

Primary entities:

Mapper notes:

• Prefer stores for product catalog migration, not ecommerce.
• variant data is typically modeled under product APIs rather than as a standalone top-level app.
• If the source has faceted product groupings, map them first to category; use custom collections only when the source model exceeds Wix's native merchandising structure.
• Product tags have a native Wix target. Do not mark them skipped or route to CMS. Create tags via POST /tags/v1/tags with fqdn: "wix.stores.catalog.v3.product", crosswalk the IDs, and set tags.publicTags.tagIds[] when creating products. Max 100 tags per FQDN. Create tags before products.

bookings

Main page:

• About Wix Bookings

Short description:

• Vertical app for service businesses. Handles services, provider availability, resources, scheduling, and customer bookings. Payment and order flow can connect into shared commerce layers.

Primary entities:

Mapper notes:

• Service catalogs belong in bookings, not stores.
• Staff and resources are distinct. Human providers should map to staff-member; rooms/equipment should map to resource.
• If the source system mixes booking payment data into reservations, split booking lifecycle from commerce/order lifecycle.

events

Main page:

• About the Wix Events API

Short description:

• Vertical app for event management, registration, ticketing, and guest handling.

Primary entities:

Mapper notes:

• Use event, ticket-definition, and ticket for ticketed-event catalogs.
• Use rsvp and event-guest for RSVP-only sources.
• If the source system has attendee records without event-level structure, document the lossiness and create an event grouping strategy before import.

restaurants

Main pages:

• About the Menus API
• Reservations API introduction

Short description:

• Vertical app family for food businesses. Covers food catalog structure, restaurant reservations, and restaurant-specific operations.

Primary entities:

Mapper notes:

• Restaurants spans multiple subdomains: menus, reservations, and in some cases restaurant ordering.
• Menu catalogs should not be mapped to stores.product unless the migration intentionally flattens restaurant content into a generic catalog.
• The old Restaurants Orders and Catalogs docs are still useful for legacy migrations, but prefer the newer Menus and Reservations APIs when possible.

pricing-plans

Main page:

• About Wix Pricing Plans

Short description:

• Vertical app for memberships, subscriptions, bundles, and access plans. Often composes with Bookings, Events, Blog, and Members.

Primary entities:

Mapper notes:

• Pricing Plans is not the same as generic payment transactions.
• Use plan for memberships/bundles/subscriptions and pricing-plan-order for subscriptions purchased by members.
• If the source platform tracks remaining credits or entitlements, document whether Wix native benefit-program behavior is sufficient or whether extra CMS/custom logic is required.

payments

Main page:

• About Wix Payments

Short description:

• Payment-processing infrastructure used by commerce-enabled Wix solutions. It is not a replacement for ecommerce.order; it handles transaction processing.

Primary entities:

Mapper notes:

• Historical payment records may map to payment transactions, but the business transaction usually still belongs to an order, booking, or plan order.
• Do not map catalog or customer data into payments.

crm

Main pages:

• About the Contacts API
• About the Members and Contacts APIs

Short description:

• Customer identity and segmentation layer centered on contacts and CRM metadata.

Primary entities:

Mapper notes:

• Use crm.contact for person/company records even if the source platform calls them customers, clients, leads, or subscribers.
• Use labels and extended fields before defaulting to a custom collection for lightweight CRM enrichment.

members

Main page:

• About the Members APIs

Short description:

• Site membership and community model layered on top of contacts, with profile, privacy, badge, and member-profile extension support.

Primary entities:

Mapper notes:

• A member is not identical to a contact, though the two are related.
• If the source platform has authenticated end users with profile data, map account identity to member and broader person data to contact where appropriate.

blog

Main page:

• About the Blog APIs

Short description:

• Blog content model for editorial content and content categorization.

Primary entities:

Mapper notes:

• Use native blog entities when the source content is editorial publishing content.
• If the source has custom structured content that exceeds blog post semantics, consider cms instead.

cms

Main pages:

• About the Wix Data APIs
• About Collection Management

Short description:

• Generic data layer for custom collections and items. This is the default fallback when no native business app entity is sufficient.

Primary entities:

Mapper notes:

• Use cms only when the source concept does not fit a stable native Wix business entity, or when the business requires custom structured data beyond the native app model.
• When falling back to cms, explicitly explain why native stores, bookings, events, pricing-plans, crm, or members entities are insufficient.

Classification heuristics for rp-mapper

Use these heuristics before inventing custom targets:

1. If the source entity represents a sellable good with variants, inventory, or merchandising structure, start in stores.
2. If it represents a purchasable service with providers, schedules, or availability, start in bookings.
3. If it represents a live/virtual gathering with attendees, tickets, or RSVPs, start in events.
4. If it represents menu/catalog content for a food business or restaurant reservations, start in restaurants.
5. If it represents subscriptions, memberships, bundles, or entitlements, start in pricing-plans.
6. If it represents carts, checkouts, or orders across verticals, start in ecommerce.
7. If it represents customer identity or segmentation, start in crm and members.
8. If it represents editorial publishing, start in blog.
9. If none of the above fits cleanly, use cms and document the gap.

Maintenance notes

• Prefer first-party Wix docs under dev.wix.com for updates.
• Update this file when Wix introduces a new stable business solution or materially changes entity boundaries.
• Preserve the explicit eCommerce vs Stores distinction. That boundary is important for migration planning and import code generation.