Glossary

This is a reference, not something to read top to bottom. Skim it once so you know what's here, then come back when a term in another page doesn't click. For how these pieces relate to each other, see Concepts.

Terms are grouped by topic: the people first, then the product layers, then the app model, then storefronts and channels, then integration workflows, then how tenants and data work, then identity and the API, and finally the acronyms. Where a term means something different on platforms you may know — Shopify, commercetools, Shopware — the entry says so, and each group that carries such a comparison dates it.

People

End customer — The B2B company running its commerce business on revenexx (a Mittelstand wholesaler, distributor, or manufacturer). They work in Cockpit at app.revenexx.com. They don't write code; they configure.

Buyer — The person who places orders in a storefront: a purchaser at one of the end customer's own business customers. They never see Cockpit.

Partner — Agencies and system integrators who deliver commerce projects for end customers. They build storefronts, write custom apps, set up integrations, and operate the platform on a customer's behalf. They build public apps for the App Marketplace; the operator decides what is listed.

Operator — The party that runs the platform itself: revenexx, or a hosting partner running it for a region or a group of customers. Most of the time you never deal with them directly — the one place it matters is publishing, because a public app reaches the App Marketplace only once the operator approves and publishes it. Submitting an app and having it listed are two separate steps, and the second is not yours.

Developer — You. The person extending revenexx — at a partner, at revenexx, or on an end customer's own team. This documentation is written for you.

Product layers

Comparisons in this group describe Shopify, commercetools and Shopware as of September 2026.

Revenue Cloud — The complete revenexx B2B commerce platform: the six Studios, the apps, the storefronts and the APIs, all over one tenant-scoped data core. When the docs say "the platform", this is what they mean. How the pieces relate is on Concepts.

Studio — A workspace inside Cockpit for one kind of work. There are six: Commerce Studio for selling, Experience Studio for storefronts, App Studio for apps, Integration Studio for workflows, Analytics Studio for dashboards, and AI Studio for agents and automation. Studios are not separately licensed products or separate systems — all six sit over the same tenant data.

Commerce Studio — The core commerce capabilities — catalog, pricing, orders, checkout — delivered as apps.

Experience Studio — The storefront layer. Standard storefronts are built on Nuxt 4 with the Cover design system and visual page composition. Custom storefronts can be built against the platform's APIs and SDKs when the standard template doesn't fit.

App Studio — The runtime and marketplace for revenexx Apps. Each app is a self-contained module (data model, optional UI, optional code). Includes the core apps grouped into domains (Intelligence, Catalog, Commerce, Customer, Marketing, Sales) plus any custom apps you or partners build.

Integration Studio — Visual workflow automation for connecting Revenue Cloud to ERP, PIM, CRM, and other enterprise systems.

Analytics Studio — The dashboard layer for end customers: a self-service dashboard builder plus pre-built KPI dashboards over the tenant's own data.

Cockpit — The admin interface for end customers at app.revenexx.com. Its UI is composed from the extension points that installed apps declare. It plays the role the Shopify admin or the Shopware Administration plays elsewhere. Unlike Shopware, where an app's admin modules are embedded pages, a revenexx app extends Cockpit declaratively, through the extension points its manifest declares.

AI Studio — The intended AI workspace: agents, insights, and automations over your tenant's data, growing in autonomy. It is a preview today: the Cockpit screens render fixture data and there is no public API, so don't build against it or quote its screens to a customer. AI that does work now is MCP and the Integration Studio translation node — see AI Studio for the current list.

App model

Comparisons in this group describe Shopify, commercetools and Shopware as of September 2026.

revenexx App — A self-contained commerce app: its own data model, optional Cockpit UI, optional code. Declared in JSON files rather than wired up by hand. How far it reaches — one tenant or every tenant — is set by its app type, and each tenant's data is kept separate either way. This differs from Shopify or commercetools, where an app is normally a service running outside the shop's own data model, wired up over OAuth and webhooks: a revenexx App runs on the platform, and its tables, UI and permissions are part of the platform's own model.

Manifest (manifest.json) — App identity and contract. name, vendor, version, title and type are required; then dependencies, peer dependencies, permissions, events, and schedules. Comparable to Shopware's manifest.xml or a package manifest: the one file that tells the platform what the app is and what it needs. See the Manifest Reference.

App type — manifest.type, the required field that decides reach: private (only the owner tenant may install or invoke it) or public (any tenant may, once the operator publishes it). Independent of pricing — see Private or Marketplace.

schema.json — The app's data model (its tables). Applied automatically when the app is installed; Git history provides the migration trail.

cockpit.json — Cockpit UI extension points: navigation items, views, widgets, and action buttons.

settings.json — Per-tenant and per-market configuration. Cockpit renders the settings forms automatically.

billing.json — Pricing only: free, paid (subscription plans), or included with a billing package. Orthogonal to app type — every combination of reach and pricing is legitimate. For a public app it also carries the Marketplace listing.

Extension points — The declarative UI hooks in cockpit.json: navigation (sidebar items), views (full-page routes), widgets (dashboard cards), action_buttons (cross-app buttons).

Permissions — The single access register in manifest.json: everything the app is allowed to reach, one entry per grant. An app declares no access by default. Each entry carries exactly one resource key naming its kind — entity, identity, capability, outbound, storage, ai, mail, secret or inbound. The customer reads the whole register and consents to it at install. There is no separate policies block.

How much of that the platform enforces depends on the class. entity, identity and capability are enforced today. outbound is honoured as declared intent while enforcement is still being built, and storage, ai, mail, secret and inbound are declarable but not yet proven. For those six the register is a statement of intent rather than an enforced boundary — don't present it to a security review as one. See Permissions, which tracks the current state.

Schedules — Named cron entries in manifest.json that have the platform invoke the app on a recurring basis, per installed tenant. The app is told which schedule fired, so one app can serve several jobs.

Peer dependencies — Apps that are required but not installed automatically. The customer installs them explicitly — useful when a dependency is paid or optional.

Lifecycle events — Platform events for an app's lifecycle (app.installed, app.uninstalled, app.upgraded, tenant.provisioned). Apps subscribe via events.listens.

Public App — type: public. Once the operator publishes it, any tenant may install it and it appears in the App Marketplace.

Private App — type: private. Only the owner tenant may install or invoke it, and it is never listed in the Marketplace. The usual starting point for partner work, and a full app in every other respect — its own tables, capabilities, Cockpit screens and schedules. It still needs a billing.json, typically just type: "free".

Included App — Not a reach of its own: a type: public app whose billing.json declares type: included. This is how the platform's own commerce apps reach tenants.

App Marketplace — The catalog where customers browse and install public apps. It plays the role of Shopify's App Store or the Shopware Store. Listing is gated: a partner submits, and the operator approves and publishes. Private apps never appear in it — they deploy straight to their owner tenant.

Core apps — The revenexx-provided apps across the six domains: Intelligence, Catalog, Commerce, Customer, Marketing, Sales.

Storefronts and channels

Comparisons in this group describe Shopify, Vercel and Netlify as of September 2026.

Site — A deployed storefront: the platform entity that holds a storefront's deployments, build configuration, environment variables and logs, with its domains attached in Cockpit. The code a site runs is a theme; the commerce data it shows lives in the tenant. If you know Vercel or Netlify, a site is closest to a project there — with the difference that domains and DNS are a Cockpit action here, not an API call. It is not a "store" in the Shopify sense either, because the shop's data belongs to the tenant, and one tenant can run several sites. Managed in Experience Studio.

Market — A distinct business context within a tenant — a country, region, storefront, or any segmentation — managed by the markets core app. Similar in spirit to Shopify Markets: a market here is whatever segmentation the business needs.

Theme — The storefront codebase a site runs: a Nuxt 4 project built on the reference theme's layer chain, declared by a theme.json manifest, deployed to a site from Git, the CLI, or by upload. See Build the theme.

Channel — The route an order arrives through: storefront, punchout, marketplace, API, point of sale — a fresh tenant is seeded with those five, and the tenant can rename, retire or add their own. ("Punchout" is the B2B pattern where a buyer shops from inside their own procurement system and the basket is handed back to it.) Carts, orders and price lists reference a channel, so the business can see and price by route. Shopify treats sales channels as a fixed set you connect to; here a channel is a record the tenant defines, managed by the channels core app.

Integration workflows

Comparisons in this group describe n8n and Zapier as of September 2026.

Workflow — A visual automation in Integration Studio: nodes wired on a canvas, started by a trigger, executed durably per tenant with a step-by-step run history in Cockpit. A failing step is retried automatically — three attempts by default. Once those are exhausted the run fails and waits for a person: from Cockpit you retry it, or resume it from the failed step. The concept matches an n8n workflow, or what Zapier calls a Zap — the difference is that it runs inside the platform, tenant-scoped, next to the data it moves.

Node — One step on a workflow canvas: an HTTP call, a transform, a branch, an SFTP download, a storage upload. Integration Studio ships 52 built-in nodes, and you can write your own. Nodes are connected by edges, which carry data from one step to the next.

Trigger — What starts a workflow run: manual, schedule, webhook, or a platform event. Whether the caller waits for the result is set by the workflow's own execution mode rather than by the trigger — see execution modes.

Tenants and data

Comparisons in this group describe commercetools as of September 2026.

Organization — The customer's account: the legal and billing entity. Identified by org_id. Owns users and tenants.

Tenant — A workspace under an organization, identified by tenant_id. A tenant holds its own isolated application data. An organization can have several tenants (for example one per market or brand). A tenant is not a "store": the storefront is a site, and one tenant can serve several. If you know commercetools, a tenant is closest to a project there.

org_id — An immutable lowercase kebab-case slug (e.g. acme-holding) that identifies an organization. Unique across all organizations.

tenant_id — An immutable lowercase kebab-case slug (e.g. acme-eu) that identifies a tenant. You send it as the X-Revenexx-Tenant header.

Tenant scoping — Every request names one tenant, and the platform — not your query — is what holds the request inside it. You never write tenant filters yourself, and you cannot reach another tenant's data by omitting one or getting one wrong. This covers application data; users and billing belong to the organization above the tenant.

Identity and the API

ID — The revenexx identity service at id.revenexx.com. Customer and partner users sign in here; admin sign-in uses OpenID Connect.

Customers / auth — Buyer and customer accounts, reached through the API gateway. Buyer authentication for storefronts is separate from admin sign-in.

API gateway — The single entry point at api.revenexx.com. Every integration calls /v1/… here. The per-tenant OpenAPI document is at /v1/openapi.json.

Authentication — A request authenticates with either a bearer token (Authorization: Bearer <token>) or an API key (X-Revenexx-Api-Key), and always names its tenant with X-Revenexx-Tenant.

API key — A machine-to-machine credential, created in Cockpit, sent as X-Revenexx-Api-Key. Scoped to one tenant with its own permissions.

JWT — A bearer token that carries the user's identity and tenant. Issued when a user signs in through ID.

Search — Full-text and faceted search over a tenant's collections, with autocomplete and typo tolerance.

Storage — Per-tenant file storage. Upload through the API; serve and transform files from your own domain.

Messaging — Transactional and marketing email for a tenant.

Events — The platform's event stream. Emit business and platform events; react to them with webhooks.

Webhooks — Receive platform events at your own endpoint, and ingest signed events from external systems.

Acronyms