App Studio

This section is for backend developers who are building custom commerce apps — either for a specific customer's unique business needs, or for distribution through the public App Marketplace where any customer can install them. In Cockpit, customers discover, install, and manage those apps in App Studio; this section is the developer's side — how you build what they install. New here? Start with the tutorials.

A revenexx App is the primary building block of installable business logic. Each app is a self-contained package: a data model, a UI extension, optional TypeScript code, and metadata about its dependencies and permissions. The platform takes care of multi-tenancy, deployment, API generation, lifecycle, and the marketplace mechanics. You focus on what the app actually does.

What is an App, concretely

When you ship an app, what gets deployed is up to five JSON files plus optional TypeScript code:

• A manifest that declares the app's identity, dependencies on other apps, and which platform capabilities it needs (outbound HTTP, event publishing, storage).
• A schema that defines the database tables the app owns. The platform creates them, scopes every row to the tenant for multi-tenancy, and exposes a REST + GraphQL API automatically. You don't write migrations or API endpoints.
• A Cockpit integration file declaring the UI surface the app adds to Cockpit: a sidebar entry, full-page views, dashboard widgets, action buttons on other apps' pages.
• A settings schema for per-tenant configuration. The platform stores the values; Cockpit auto-renders the configuration form.
• A billing declaration: free, paid (with subscription plans), or included (bundled with a higher-tier package).

For non-trivial apps, you add TypeScript functions that run on the platform's serverless runtime — that's where your custom logic lives. For trivial apps that just need a tenant-scoped CRUD interface, you might write no code at all.

Custom apps vs. core apps

revenexx ships a set of core apps that cover the standard B2B commerce surface area: Products, Pricing, Orders, Checkout, Inventory, Customers, Promotions, Quotes, and so on. Customers usually start with these and configure them.

A custom app is what you build when the core apps don't fit. That happens when:

• The customer has an unusual domain object — batch-tracked chemicals, serialized medical devices, configurable industrial cable assemblies. The standard Product model doesn't capture what they need.
• The customer has industry-specific workflows — pharmaceutical recall handling, ATEX-zone shipping validation, EDIFACT message routing.
• The customer wants to expose internal tools to their own employees inside Cockpit — a custom report, a bulk-edit interface, a quick action button on every order.

In all those cases, you write an app rather than hacking the storefront or building a side service, because:

• Cockpit users get a native UI that looks and feels like every other revenexx feature.
• Tenant isolation is automatic — you can't accidentally leak data between customers.
• The lifecycle (versioning, upgrades, uninstall) is handled by the platform.
• If the customer expands to a second tenant or buys another business, your app comes along.

What you'd typically build with this

A configurable-quote app for a manufacturing supplier. The customer's sales team needs to build complex quotes with configurable products, tiered discounts, and approval workflows. You define a quotes table and a quote_lines table in schema.json, a Cockpit view for the quote builder in cockpit.json, and TypeScript functions for the quote-validation logic. Sales staff log into Cockpit and use it like any built-in app.

A serial-number tracking app for medical devices. Each device has a serial number that follows it from inventory through sale and into post-sale service tracking. You add a device_serials table, an extension point on the existing Orders view to show device-level shipment status, and a device.shipped event that downstream apps can subscribe to.

A regulatory-compliance app for chemicals. The customer needs to attach safety data sheets (SDS) to products, enforce hazmat shipping rules at checkout, and produce regulatory reports. You add tables, a Cockpit settings page for compliance rules, action buttons on the Orders page for "Mark hazmat-validated", and an event subscription that prevents fulfillment until SDS is attached.

In each case, you write the part that's specific to the customer's domain. The rest — Cockpit UI scaffolding, multi-tenant database, deployment pipeline, event bus — comes from the platform.

What's in this section

• App Model Concept — Read this first. Why apps are declarative, how the five JSON files fit together, and a complete worked example of a small app.
• Manifest Reference — Field-by-field reference for manifest.json. Dependencies, peer dependencies, permissions, policies, events.
• Schema Reference — Field-by-field reference for schema.json. Column types, indexes, foreign keys, migrations, and what the platform exposes automatically.
• Cockpit Integration — How to extend Cockpit's UI: sidebar items, views, widgets, action buttons. What you write in Vue, and how it ends up in Cockpit.
• Lifecycle — Semantic versioning, auto-upgrade rules, lifecycle events (app.installed, app.upgraded, …), and how schema migrations are applied safely.
• Billing & Events — Two topics: pricing models for marketplace distribution, and the event bus apps use to communicate with each other.

Deep-dive references

These reference pages cover individual platform mechanics in more depth:

• App Model — How apps declare identity, schema, settings, Cockpit extensions, and billing.
• Schema migrations — How schema.json is applied to your tables with tenant isolation.
• Auto-generated data APIs — Auto-generated REST and GraphQL APIs from your app's tables.
• Market Concept — How apps are distributed and installed across tenants.
• Policies — Outbound access, event bus, and storage policies.

Where to go next

If you haven't read Platform Overview yet, start there for the big picture. If you're already oriented and want to build, go to App Model Concept — it walks through a complete app end-to-end so the rest of the section makes more sense.