Concepts

Read this once you know what revenexx is and want the words for it. This page is the vocabulary: it names the nouns that recur on every other page, shows how they relate, and says which piece you touch for which kind of work. It is the page to keep open while you read the rest of the docs.

revenexx Revenue Cloud is a multi-tenant B2B commerce platform, and "the platform" throughout these docs. It ships the plumbing every B2B commerce project would otherwise rebuild, so you build only what is specific to your customer's business — the Platform Overview makes that case in full.

The concept model

The Studios, the app model, sites and the data core each link to their own docs.

Top to bottom: people use one of two surfaces, Cockpit is organised into Studios, much of what the Studios manage is delivered as apps, and sites, apps, workflows and Cockpit all read and write one tenant-scoped data core.

How the pieces relate

A tenant is the unit everything else sits inside. An organization is the customer's account and owns one or more tenants; a tenant is what every request names and what every row belongs to. Keeping them apart is the platform's job, not your code's — the Architecture Overview has what that means when you write a query.

One data core under everything. Sites, apps, workflows and Cockpit are all views over the same tenant data — there is no separate store per Studio to keep in sync. Everything reaches that data through one API gateway, api.revenexx.com, and every request to it names exactly one tenant.

Cockpit is the admin surface, and it is composed, not built. End customers and partners run the business in Cockpit at app.revenexx.com. Its navigation, views and widgets come from the extension points that installed apps declare — install an app and its UI appears, uninstall it and it's gone.

Studios are workspaces, not separate products. A Studio is the area of Cockpit where one kind of work happens; the table below says which Studio owns which work. You don't license or deploy Studios individually — they're how one platform is organised, and all of them sit over the same tenant data.

Apps are the functional units. A revenexx App is a self-contained module: its own data model, optional Cockpit UI, optional code, all declared in JSON files. The commerce capabilities themselves — catalog, pricing, orders, checkout — are apps revenexx ships; your custom work takes the same shape. Its manifest declares the permissions the app needs, and the customer reads that list on a consent screen at install.

Publishing to the Marketplace is optional. A public app becomes installable by any tenant once the operator — the party running the platform itself, revenexx or a hosting partner — publishes it to the App Marketplace. Partners build public apps; the operator decides what is listed. A private app skips the Marketplace entirely and deploys straight to its owner tenant — the usual starting point for partner work. See Private or Marketplace.

Sites are where buyers shop. A site is a deployed storefront: the platform entity that holds a storefront's deployments, build configuration, environment variables and logs. Its domains are attached in Cockpit rather than through the API. The code a site runs is a theme; the commerce data it shows lives in the tenant, not in the site.

Channels name the route an order arrived by. An order a buyer places carries a channel — a record the tenant defines, not a fixed enum. A fresh tenant is seeded with five and can rename, retire or add its own; the glossary names them. Carts, orders and price lists all reference one, so the business can report and price by route.

Workflows connect the outside world. The customer's ERP, PIM and CRM stay their systems of record where needed; workflows in Integration Studio move data between them and the platform — visually built from nodes, durable, and observable in Cockpit. A failing step is retried — by default three attempts in total, with exponential backoff — and when those are used up the run stops and waits for a person to retry or resume it from Cockpit. A node can instead be wired to route its error down a branch you define, and a run that does that finishes green, so choose it deliberately.

Which piece you touch

Whatever you're building, start where that kind of work lives.

Coming from Shopify, commercetools or Shopware? Several of these terms exist there with different meanings — the glossary flags the differences term by term.

Where to go next

• Architecture Overview — the one to read next: the same pieces at system level, with request flows and tenant isolation.
• Quick Start — or skip ahead and deploy your first app in about 15 minutes.
• Glossary — every platform term, one paragraph each.
• Platform Overview — if you skipped it: who uses the platform, what you can build, and why it's a platform rather than a stack.