Platform Overview

Start here if revenexx is new to you. This page is the product tour: what Revenue Cloud is, the four kinds of people around it, the six Studios it is organized into, and the kinds of projects it is built for. It does not define the vocabulary or trace a request — Concepts and the Architecture Overview do that, in that order.

What is revenexx Revenue Cloud?

revenexx Revenue Cloud is a B2B commerce platform that small and mid-sized companies use to run their online sales business — and that developers, system integrators, and partners extend with custom apps, automated workflows, and bespoke storefronts.

It exists because every serious B2B commerce project ends up rebuilding the same infrastructure before it can build anything of its own. revenexx ships those pieces as a coherent platform, so the team building a commerce solution can focus on the parts that are actually unique to their customer's business.

The closest comparison is Shopify for B2B — but for the enterprise end of the market: deeply integrated with ERPs and PIM systems, customizable down to the database schema, and built around modular apps that customers install, configure, and combine like building blocks.

Who uses it

Four kinds of people show up around the platform, each with their own needs:

End customer — the company running its commerce business on revenexx. A "Mittelstand" wholesaler, distributor, or manufacturer who buys a subscription, configures their catalog, hooks up their ERP, and goes live. They live in Cockpit — the admin UI — and don't write code.

Buyer — the customer of the customer. The procurement officer at a hospital ordering medical supplies, the workshop owner ordering parts. They use a storefront that the end customer (or a partner) built on top of revenexx.

Partner — agencies and system integrators who deliver commerce projects to end customers. They scope projects, build storefronts, write custom apps, set up integrations, and operate the platform on the customer's behalf.

Developer (you) — the person extending revenexx, whether you're employed at revenexx, at a partner, or at the end customer's own IT team. You write the apps, build the integrations, and design the storefronts.

This documentation is written for the last group. The rest is context that helps you understand why things are designed the way they are.

What you can build

Three concrete examples — these are the kinds of projects revenexx is designed to support:

1. A B2B webshop with a custom checkout. A distributor wants buyers to log in with their account, see contract pricing, and place orders that flow directly into the ERP. You build the storefront on Nuxt 4 (using Blökkli to let the marketing team edit pages), wire up authentication, customize the checkout flow with schema-driven forms, and connect it to the catalog and order apps. Multi-tenancy, identity, and order persistence are already solved by the platform.

2. An automated nightly ERP order sync. Every night at 02:00, the previous day's order changes in the customer's SAP system need to reach revenexx. You build this in Integration Studio without writing a backend: a scheduled trigger, an HTTP node that hits SAP's REST API, a JSON Transform node that reshapes the payload into revenexx's order format, and an HTTP POST that posts the updates back. The platform handles retries, durability, and observability.

3. A custom inventory app for a specific vertical. The customer has an unusual stock-keeping process (e.g. batch-tracked chemicals or serialized medical devices). You write a custom app: declare the data model in schema.json, the UI extensions in cockpit.json, the business logic in a Node function at src/main.js. The platform handles tenant isolation, REST API generation, deployment, and lifecycle. You write only the parts that are specific to that customer.

Why a platform, not a stack

You could build any of those three projects yourself, from scratch. Many teams do — and they all end up reinventing the same primitives:

• Multi-tenant data isolation — one customer's data unreachable from another's, enforced below the query rather than in it
• Customer and buyer identity, with SSO and role-based access
• A way to configure apps per tenant without redeploying code
• A workflow engine for long-running integrations
• An admin UI that adapts to whatever apps a given customer has installed
• Operational infrastructure: provisioning, billing, deployment, monitoring

revenexx provides those as the substrate. The principle is declarative over imperative: instead of writing code to spin up tables, register routes, and wire up authentication, you declare what you need in JSON (manifest.json, schema.json, cockpit.json) and the platform builds it. You write code only for the parts that are genuinely custom — your business logic.

Cockpit: where customers live

Cockpit is the unified admin UI — a Vue.js single-page application that the end customer uses to run their commerce business. It's the surface area for everything: managing the catalog, configuring storefronts, building workflows, monitoring orders, installing apps, inviting users.

What makes Cockpit interesting from a development perspective: it's dynamically composed. When a customer installs an app, that app declares its UI extensions in cockpit.json — new navigation items, custom views, dashboard widgets, action buttons on existing pages. Cockpit reads those declarations at runtime and weaves them into the UI. There's no central Cockpit codebase that needs to be modified per customer.

The six Studios

revenexx is organized into six workspaces, called Studios. A Studio is the area of Cockpit where one kind of work happens — you don't license or deploy them separately, and all six sit over the same tenant data.

Commerce Studio — Selling

The core commerce capabilities — catalog, pricing, orders, checkout — delivered as apps and surfaced in Cockpit. It's the backbone the other Studios build on: storefronts present it, integrations feed it, analytics measure it.

Experience Studio — Storefronts

The buyer-facing side: storefronts that customers shop in. The standard build is Nuxt 4 with the Cover design system and Blökkli for visual page composition, so marketing teams can edit landing pages without engineering involvement. The checkout is schema-driven (FormKit), making it easy to customize per customer. For projects where the standard storefront doesn't fit, partners build fully custom frontends against the platform's REST API.

What you'd typically build here: product catalogs with faceted search, role-based pricing displays, multi-step checkouts, account self-service portals.

App Studio — Apps and the App Marketplace

The platform's business logic, modularized as Apps. Each app is a small, declarative package: a manifest, a database schema, optional UI extensions, optional billing rules, and (for non-trivial apps) a Node function at src/main.js that the platform runs for you.

There are two kinds of apps:

• Core apps that revenexx provides, covering the standard B2B commerce surface area: Products, Prices, Carts, Orders, Inventory, Customers, Procurement and Order Lists among them. The API reference is the live list — a tenant's surface grows as apps are installed, so read it there rather than from a list on a page.
• Custom apps built by partners or end customers for use cases the core apps don't cover.

The App Marketplace is where customers browse, install, and configure apps — both revenexx's own and ones built by partners.

What you'd typically build here: a custom inventory model, an industry-specific quoting tool, an integration with a niche third-party service that needs a UI in Cockpit.

Integration Studio — Workflow Automation

For everything that happens between revenexx and the customer's other systems. ERP order syncs, PIM product imports, CRM contact updates, scheduled price refreshes, real-time inventory checks.

Workflows are built visually: a canvas with drag-and-drop nodes for HTTP requests, transforms, conditionals and loops, started by a manual, scheduled, webhook or event trigger. A workflow can be started and left to run, or called and waited on for its result — the same durable run either way. See how workflows run.

What you'd typically build here: every kind of "data needs to move from system A to system B" workflow. The unique advantage is that workflows are visible, configurable, and observable in Cockpit — not buried in someone's custom Node.js codebase.

Analytics Studio — Reporting

Self-service dashboards and pre-built KPI views over the customer's own data. Customers see only their own data. There is no public analytics API: the shipped, versioned contract you build against is an analytics.json in your app, alongside the event stream and the commerce API. Analytics Studio has the three paths that work today and a dated list of what does not exist yet.

AI Studio — Agents and automation (preview)

AI that works on your data, not a chatbot bolted on. The intent is assistants that answer grounded questions about a tenant's own commerce data, findings surfaced without being asked and — further out — actions taken inside rules an operator sets. Today it is a preview: the Cockpit screens render fixture data and there is no public API, so don't build against it or show it to a customer as shipped. The AI that does work now is MCP and the Integration Studio translation node; AI Studio keeps the current list.

Behind the scenes: automatic setup

You don't provision anything by hand. When a customer signs up — or installs an app — the platform sets up everything that app needs: the tenant's isolated data, identity, storage, search, messaging, and the default apps that come with their plan.

Multi-tenancy: the one-line version

Every customer's data is isolated from every other's. Each request names its tenant with the X-Revenexx-Tenant header, and the platform — not your code — scopes the data to it. The header only selects the tenant; the credential you send is what grants access to it, so a key or a token cannot reach a tenant it does not belong to.

What that means when you write a query is set out in the Architecture Overview; the columns behind it are in Tenant isolation. What an app may do inside a tenant is a separate, weaker boundary — Permissions tracks which classes are actually enforced.

What's next

You now know the shape of the platform — who it is for, what gets built on it, the six Studios, and where Cockpit fits. Next, the vocabulary, then the system:

• Concepts — the concept model on one page: how Cockpit, Studios, apps, sites, the Marketplace and the data core relate, with the relationship diagram.
• Architecture Overview — the layers you build on and how a request flows from the storefront to the data and back.
• Quick Start — Hands-on: scaffold and deploy your first app in 15 minutes.
• App Model Concept — How declarative apps work: manifest, schema, Cockpit extensions, and where you write code.