Adobe Commerce Certified
Official Shopify Expert
Mission Report • B2B/B2C Marketplace Platform Engineering

Headless multi-vendor marketplace on Magento 2

We designed and delivered a fully headless marketplace platform on Magento 2 using 10 custom modules and a bespoke GraphQL API, giving the client operational control across vendor onboarding, catalogue logic, assisted ordering, and analytics.

Platform architecture, module delivery, and operational rollout UK Delivery Confidential marketplace operator
Platform model

Headless Magento 2 marketplace

Custom scope

10 bespoke modules + GraphQL API

Core principle

Vendor-scoped control without core forks

The brief / challenge

The client needed a marketplace architecture that could support multi-vendor operations at catalogue level, while giving each vendor safe operational autonomy and preserving central governance.

Diagnostic Symptoms

  • Single-SKU products needed multiple vendor offers without duplicating catalogue entities
  • Vendor teams needed self-service workflows with role-based subaccounts and permissions
  • Authentication needed configurable OTP/2FA providers to match operational and compliance constraints
  • Operations required in-store POS, click & collect, and vendor communications in one delivery surface

Structural Root Causes

  • Conventional catalogue modelling made vendor offer management brittle and difficult to scale
  • Marketplace workflows spanned multiple operational contexts but lacked one coherent control layer
  • Standard module combinations did not provide the required GraphQL-first delivery model

Project Evidence

Delivery architecture
10 custom Magento 2 modules
API model
Fully bespoke GraphQL-first implementation
Data boundaries
Strict vendor-scoped data isolation
Commerce logic
Single-SKU / multi-vendor offer support

The platform moved us from fragmented workflows to a controllable marketplace operating model, without sacrificing technical depth or future extensibility.

Mps

Marketplace programme stakeholder

Confidential client team

Overview

What was built and re-architecture approach

Model the marketplace around offers, not product duplication

Implemented a single-SKU / multi-vendor offer architecture so vendors could compete on one catalogue entity while preserving clean product governance.

Deliver modular Magento 2 extensions with clear boundaries

Built ten custom modules to separate concerns across auth, vendor management, trading packages, analytics, communications, and POS.

Expose platform capability through a bespoke GraphQL layer

Created GraphQL-first contracts for vendor operations, marketplace data, and checkout-adjacent interactions across headless surfaces.

Protect governance with scoped access and security controls

Applied configurable OTP/2FA and role-based subaccounts with vendor-scoped isolation to keep autonomy and control balanced.

Before

Marketplace operations relied on fragmented workflows, limited vendor autonomy, and rigid catalogue patterns that constrained scale.

After

A headless, GraphQL-first Magento marketplace platform with modular controls, vendor-safe operations, and stronger release confidence.

Playbook Checklist

Magento 2 modular architecture (10 custom modules)Bespoke GraphQL-first API deliverySingle-SKU / multi-vendor offer modelLocation-based vendor coverage resolutionConfigurable OTP and role-based subaccountsVendor analytics, POS, and communications tooling

Key Outcomes

Validated
Marketplace operations could scale without compromising catalogue integrity or vendor data boundaries
Vendors gained self-service control while platform operators retained governance and visibility
Headless API delivery enabled faster product extension across marketplace touchpoints
Operational tooling connected online and in-store journeys through one coherent platform model
Key Platform Capabilities

The solution surface

  • Vendor self-service operations with scoped access controls
  • Role-based vendor subaccounts for delegated team workflows
  • Configurable OTP and multi-provider 2FA authentication model
  • Single-SKU catalogue with multi-vendor offer orchestration
  • Location-aware vendor coverage resolution for offer eligibility
  • Vendor analytics, trading packages, and communication tooling
  • Public vendor profiles plus in-store POS and assisted ordering

Technical Depth

Engineering detail that mattered

Modular Magento 2 implementation across ten custom modules to keep extension boundaries explicit and maintainable.

GraphQL-first delivery model to expose business capability cleanly to headless clients and future surfaces.

Vendor-scoped data isolation applied across account, catalogue, and operational workflows.

Marketplace logic engineered around offer composition and selection rather than product duplication.

What this demonstrates

Validated frameworks for stakeholders

  • Ability to deliver platform-grade marketplace engineering in Magento without relying on fragile core forks.
  • Practical balance between vendor autonomy and central operational governance.
  • Technical architecture that supports both current operations and incremental capability rollout.
  • Strong execution across catalogue modelling, security controls, and day-to-day marketplace operations.

This engagement aligns directly with our Magento engineering, marketplace operations, and PWA delivery services where platform reliability and extensibility need to move together.

Visual Documentation

System architecture & UI reference

Step 01

Marketplace - sku offer

Proposed SKU-level offer model with multi-vendor composition, location-aware routing, and tiered pricing.

Magento 2 single-SKU multi-vendor offer model showing vendor composition, location-aware routing, and tier pricing structure Marketplace - sku offer
Step 02

Vendor dashboard UI

Vendor self-service surface with subaccount permissions, offers, and communications tools.

Magento 2 single-SKU multi-vendor offer model showing vendor composition, location-aware routing, and tier pricing structure Vendor dashboard UI
Step 03

POS & assisted ordering

In-store assisted order flow with click & collect and vendor context.

Magento 2 single-SKU multi-vendor offer model showing vendor composition, location-aware routing, and tier pricing structure POS & assisted ordering
Step 04

Analytics panels

Marketplace and vendor analytics used for operational decision-making.

Magento 2 single-SKU multi-vendor offer model showing vendor composition, location-aware routing, and tier pricing structure Analytics panels

Interactive Platform Walkthrough

60–90 second demonstration covering offer selection, coverage resolution, vendor operations, and auth flows.

Commercially Verified Result

Relevant expansion outcomes.

The platform enabled a scalable marketplace operating model with clear control layers, supporting faster expansion into new vendor workflows without replatforming.

Marketplace operations could scale without compromising catalogue integrity or vendor data boundaries
Vendors gained self-service control while platform operators retained governance and visibility
Headless API delivery enabled faster product extension across marketplace touchpoints
Operational tooling connected online and in-store journeys through one coherent platform model

Frequently Asked Questions

Answers for teams evaluating custom multi-vendor architecture, headless Magento delivery, and vendor operating-model design.

Yes, but not natively. Magento's core catalogue model is single-vendor — one product, one price, one owner. Supporting multi-vendor offers against a shared SKU requires a custom offer layer. We built a VendorOffer model that binds a vendor to a product with its own price, stock, and fulfilment metadata, so multiple vendors can compete on the same catalogue entity without duplicating product records.
In a headless Magento 2 marketplace, the storefront and vendor-facing interfaces consume data through a GraphQL API rather than through Magento's native frontend. Magento handles product data, order management, inventory, and business logic in the backend. All vendor operations — offer management, order routing, analytics, authentication — are exposed as typed GraphQL queries and mutations. The frontend can be any stack: React, Next.js, a native mobile app, or a POS terminal.
A Magento extension is a packaged, general-purpose module designed to solve a common problem across many stores. A bespoke marketplace module is purpose-built for a specific platform's operating model — with domain-specific data structures, business rules, and API contracts that a general extension cannot provide. This platform used ten bespoke modules, each scoped to a single capability domain, rather than assembling off-the-shelf extensions that would require workarounds to fit the required architecture.
Magento's native auth covers customer accounts and admin users but has no OTP or two-factor infrastructure. We built a custom authentication layer within the extension that supports three configurable modes — OTP only, password only, or password plus OTP — with provider-abstracted delivery across Twilio Verify, WhatsApp, and custom HTTP gateways. The provider is selected from Magento system config at runtime, so switching requires no code deployment.
A platform of this scope — ten custom modules, a bespoke GraphQL API, vendor auth, analytics, POS, and communications tooling — is a multi-month engagement. Simpler marketplace extensions covering offer management and basic vendor onboarding can be delivered faster. The right timeline depends on how many operational domains need custom logic versus how much can be handled by configuration and standard Magento capability. A technical assessment is the right starting point for scoping this accurately.
Vendor data isolation is enforced at the query layer, not filtered after retrieval. When a vendor authenticates, their vendor context is embedded in the JWT and resolved at the GraphQL resolver entry point. Every repository query that touches vendor-owned data — offers, orders, analytics, subaccounts — uses this context as a hard constraint. A vendor with a valid token cannot read or write another vendor's data regardless of what they pass in the request.

Planning a complex marketplace build?

Book a technical assessment to map architecture risk, integration boundaries, and delivery priorities before execution.