Overview
The Marketplace Service is the platform’s app registry and connector marketplace. Think of it as the “app store” for the Equinox commerce platform: it holds a catalogue of apps (also called connectors) that extend or plug capabilities into other platform services (cart, PIM, OMS, subscription, user, etc.), and it governs their whole lifecycle — from registration and approval, through per‑business and per‑store enablement, layered configuration, versioning, health checks and audit, all the way to deprecation and archival.
A newcomer can picture it like this:
- A provider (in‑house team or a third party) registers an app. The app declares how the platform reaches it (a deployment: an AWS Lambda, a bundled npm/Maven connector artifact, or an external HTTP service), what interfaces it implements (e.g.
PaymentProcessorV1), and what capabilities it offers (e.g.PAYMENT). - An admin moves the app through an approval workflow (
draft → pending → approved), then enables it for a specific business and store, optionally as the default app for an interface. - Once enabled, other platform services discover the app and its effective configuration (business + store + service override layers merged together) and invoke it. Marketplace publishes
app.*events on EventBridge so those services keep their local copies in sync.
Business Value
| Capability | Business outcome |
|---|---|
| Central app/connector registry | One authoritative catalogue of every integration; no duplicated or drifting connector metadata across services |
| Approval workflow with lifecycle states | Governance and safety — only approved apps can be enabled; risky changes are gated and audited |
| Per‑business / per‑store enablement | Multi‑tenant flexibility — each merchant/store runs exactly the apps it needs, with a default per interface |
| Layered config overrides | Same connector reused everywhere but tuned per business/store/service without forking the app |
| Versioning + rollback + canary | Safe rollout of new connector versions; instant rollback and gradual (canary) traffic shifting |
| Payment provider configuration & multi‑provider routing | Merchants configure payment gateways with primary/secondary failover and weighted routing |
| Notification event/action configuration | Merchants tailor which notifications fire on which events, per channel |
| Health checks + events | Automatic detection of unhealthy external apps and platform‑wide event propagation |
| Self‑registration + API keys | Apps can register themselves at deploy time (CI/CD or cold start) using machine‑to‑machine keys |
| Full audit history + point‑in‑time snapshots | Compliance — who changed what, when, and what the config looked like at any moment |
Who Uses It
| Persona | How they interact |
|---|---|
| Platform / marketplace admin | Approves apps, enables/disables them per business & store, manages interfaces and config overrides (JWT + admin privileges) |
| App provider / developer | Registers and versions apps, self‑registers via API key at deploy time, configures webhooks and mock responses |
| Merchant / store operator | Configures payment providers, notification events & actions for their store (via admin portal → JWT) |
| Consuming platform services (cart, PIM, OMS, subscription, user) | Subscribe to app.* EventBridge events; read effective config to discover and invoke enabled apps |
| CI/CD pipeline | Emits app.deployed EventBridge events (source: custom.pipeline) that trigger self‑registration |
| Auditors | Query app/enablement change history, compare and reconstruct point‑in‑time state (marketplace:auditor) |
Core Features
| # | Feature | Description |
|---|---|---|
| 1 | App registry (CRUD) | Create, read, update, soft‑delete apps with rich metadata, deployment, interfaces, capabilities and auth config |
| 2 | Approval workflow | Lifecycle states draft → pending → approved → deprecated → archived (+ rejected, deleted) with a validated transition map |
| 3 | Quick create | One‑shot app creation with optional auto‑approve and deployment validation (npm view, Lambda dry‑run, HTTP health check) |
| 4 | Interface definitions | Register named/versioned interfaces, validate apps against them, list apps per interface, produce migration reports |
| 5 | Store‑level enablement | Enable/disable apps per store per interface, set defaults, rollback, drain (graceful wind‑down) |
| 6 | Business‑level enablement | Enable/disable apps at the business tier (prerequisite for some flows, e.g. PAYMENT) |
| 7 | Layered config overrides | Business / store / service override layers deep‑merged into an effective config, incl. serviceInstanceMap |
| 8 | Payment configuration | Per‑store payment provider config (encrypted secrets) + multi‑provider routing (primary/secondary, weighted, failover) |
| 9 | Notification configuration | Per‑store notification events, actions (EMAIL/SMS/PUSH), restricted‑event suppression, readiness checks |
| 10 | Webhooks | Register external subscribers, deliver app.* notifications, view delivery history and audit logs |
| 11 | Mock responses | Store and test mock responses embedded in an app for integration testing |
| 12 | Routing / hooks / canary | Routing strategies, pre/post hooks, canary rollout with auto‑promote/rollback |
| 13 | Self‑registration & API keys | Machine‑to‑machine app self‑registration from an app manifest + API‑key lifecycle (max 5 active) |
| 14 | Health checks | Periodic health probing of external apps with healthy/degraded/unhealthy state + events |
| 15 | Eventing | Publishes app.* / business.app.* EventBridge events; consumes app.deployed and interface/deprecation events |
Related Resources
- Admin portal — front end consuming the API (apps, enablement, config overrides, contracts, provisioning, package management).
- Consumer SDK — consumer‑side event handler and plugin used by other services to react to marketplace events.
- Shared connector packages — example bundled connectors that ship with the platform.
- Contracts / schemas — capability contracts and the app manifest schema.
- Event fan‑out rule — the rule that fans
app.*events out to consumer service Lambdas.
Revision History
2026-08-05 | JP – Created the page and added the content.