Architecture Overview
This page is for solution architects and senior developers who want the mental model before they start building. If you're writing a single app or one storefront, you don't need all of it — the App Model Concept is enough. Read this when you're scoping a larger project, evaluating revenexx, or working out where a request goes when something breaks.
It's described in three layers, high to low: who uses what, the building blocks you work with, and how a real request flows end to end.
At a glance
The platform stacks like this — every box links to the relevant docs:
Layer 1: who uses what
Four kinds of people work with the platform. Knowing which one a piece of functionality serves is the fastest way to find your way around.
Buyers place orders in storefronts. They sign in to the storefront's own customer accounts and never see Cockpit.
End customers are the companies running their commerce business on revenexx — distributors, wholesalers, manufacturers. They work in Cockpit at app.revenexx.com, which adapts to whichever apps they've installed. They sign in through ID (id.revenexx.com).
Partners (agencies, system integrators) build and operate revenexx implementations. They use the CLI to deploy apps, Cockpit to configure them, and Integration Studio to wire up the customer's ERP and other systems. They publish public apps to the App Marketplace.
Developers — you — extend the platform: apps, storefronts, and integrations, against the public API.
External systems sit at the edge: the customer's ERP, PIM, and CRM (SAP, Salesforce, Salsify, …), reached through Integration Studio.
Layer 2: the building blocks
Everything you build sits on a small set of public building blocks.
What you build in
- Cockpit — the admin UI. It's composed at runtime from the
cockpit.jsonextension points your installed apps declare; there's no central UI that hard-codes specific apps. - Commerce Studio — the core commerce capabilities (catalog, pricing, orders, checkout), delivered as apps.
- Experience Studio — storefronts. The standard template is Nuxt 4 with the Cover design system and visual page composition; go fully custom against the API when you need to.
- App Studio — where revenexx Apps run. Each app is its declared data model plus optional UI and code.
- Integration Studio — the workflow builder for cross-system integrations (see the Integration Studio Overview).
- Analytics Studio — self-service dashboards over the customer's own data.
- AI Studio — agents, insights, and automations over your tenant's data, growing in autonomy. (Its API is in progress.)
What the platform handles for you
You reach all of these through the API gateway at api.revenexx.com — one entry point, every request scoped to a tenant.
- ID — sign-in for customer and partner users.
- Search — full-text and faceted search over a tenant's collections.
- Storage — per-tenant file storage; serve and transform files from your own domain.
- Messaging — transactional and marketing email.
- Events — emit business and platform events; react to them with webhooks.
You don't run or wire any of this together. You call the gateway with your tenant and credentials, and the platform takes care of identity, isolation, search, storage, messaging, and event delivery.
Layer 3: how a request flows
The model only clicks once you trace a real request. Three examples, each showing a different aspect.
A buyer places an order
The buyer has products in their cart and clicks Checkout. The storefront's server collects the cart, validates the buyer's session, and calls the Orders app. The Orders app reads and writes the tenant's data — automatically scoped, so it only ever sees this customer's orders.
The order is written, and the Orders app emits an order.created event. Subscribers react in parallel: inventory reserves stock, messaging sends the confirmation, and any custom apps the customer installed do their part. The buyer sees the confirmation page.
The point: tenant isolation isn't something each app implements — the platform guarantees it, so one app's bug can't leak another tenant's data.
A scheduled ERP sync
At 02:00 a scheduled Integration Studio workflow fires. It fetches yesterday's order changes from the customer's SAP system, reshapes the payload into revenexx's order format, and posts the updates back. If SAP is briefly down, the workflow retries automatically; if a step fails midway, the run resumes from the last completed step — you don't write any of that retry logic. The whole run is visible in Cockpit under Integration Studio → Workflow Runs, step by step.
A live price lookup
A buyer opens a product page that needs contract-specific pricing, computed live in the customer's ERP. The storefront calls a synchronous workflow: it runs in-process, calls SAP's pricing endpoint, transforms the response, and returns — target round-trip under 100ms. Same workflow builder as the nightly sync; the only difference is async (durable, slower) vs. sync (in-process, fast).
Multi-tenancy: you only ever see your tenant
This is the design choice that affects you most. Every request names its tenant with the X-Revenexx-Tenant header, and data is automatically scoped to that tenant. You query your data normally; the platform guarantees you only ever read or write the current tenant's rows — enforced by the platform, not by your code. There's no "default tenant": without a tenant in the request, you get nothing back.
What this means in practice: you never write tenant filters, you can't accidentally omit one, and you can't reach another tenant's data even if your app has a bug.
What's next
- Quick Start — build something hands-on (about 15 minutes).
- App Model Concept — the conceptual deep-dive if you're writing an app.
- Integration Studio Overview — the workflow engine in detail.