Platform Overview

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 things: multi-tenant data isolation, customer identity, role-based admin UIs, ERP integration pipelines, headless storefront infrastructure. 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 Formily-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 price sync. Every night at 02:00, prices from the customer's SAP system need to flow into the revenexx catalog. 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 data, and an HTTP POST to the catalog API. 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 TypeScript. The platform handles tenant isolation, REST/GraphQL 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 (so customer A never sees customer B's data, ever)
• 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.

The six Studios

revenexx is organized into six product areas, called Studios. Each Studio is the workspace for a different kind of work, and each addresses a different need.

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 Blökkli for visual page composition, so marketing teams can edit landing pages without engineering involvement. The checkout is schema-driven (Formily), 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 and GraphQL APIs.

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) some TypeScript code that runs as a cloud function.

There are two kinds of apps:

• Core apps that revenexx provides, covering the standard B2B commerce surface area: Products, Pricing, Orders, Checkout, Inventory, Customers, Promotions, Quotes, and so on.
• 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 (HTTP requests, transforms, conditionals, loops, triggers). They run either as durable, long-running async jobs (for nightly imports, bulk syncs) or as sync request/response pipelines (for sub-100ms live queries like "is this in stock right now?").

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 (coming soon)

Self-service dashboards and pre-built KPI views over the customer's own data. Customers see only their own data; revenexx never aggregates across tenants.

AI Studio — Agents and automation

AI that works on your data, not a chatbot bolted on. AI Studio grows in autonomy across four stages: an assistant that answers grounded questions with sources, a copilot that surfaces opportunities before you ask, an autopilot that acts within the rules you define, and agent teams that coordinate across segments and channels. It's a Cockpit workspace today; the AI Studio API for building on it directly is in progress.

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.

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. As a developer you declare what your app needs in its JSON files; installing it wires the rest up for you.

Multi-tenancy: you only ever see your tenant

Every customer's data is fully isolated. Each request names its tenant with the X-Revenexx-Tenant header, and data is automatically scoped to that tenant — enforced by the platform, not by your code. When you write a query in an app you don't filter by tenant: you read and write your data normally and only ever see the current tenant's rows. There's no "default tenant" — without one, you get nothing back.

For the data model and how schemas are applied, see the Architecture Overview and Schema Reference.

What's next

You now know the shape of the platform — the audience, the six Studios, where Cockpit fits, why multi-tenancy is the way it is. Next, learn how the pieces actually fit together at the system level:

• Architecture Overview — the layers you build on and how a request flows end-to-end.
• Quick Start — Hands-on: deploy your first cloud function in 15 minutes.
• App Model Concept — How declarative apps work: manifest, schema, Cockpit extensions, and where you write code.