From manifest to installed

The local preview renders your manifest against mock data. Getting it in front of a merchant's operators takes four more things.

1. The capabilities your manifest names

Every write.endpoint and every api action's endpoint resolves against your app's own routes under /v1. A route with no declaration is a 404 after the operator clicks.

[
  {
    "type": "define",
    "capability": "suppliers.list",
    "version": "1.0.0",
    "route": { "method": "GET", "path": "/suppliers" },
    "response": { "title": "SupplierList", "type": "object" }
  },
  {
    "type": "define",
    "capability": "suppliers.deactivate",
    "version": "1.0.0",
    "route": { "method": "POST", "path": "/suppliers/{id}/deactivate" },
    "response": { "title": "SupplierDeactivated", "type": "object" }
  }
]

Everything declared here is published: the route is served verbatim under the gateway's /v1 prefix, and the same declaration produces the OpenAPI document, the SDK methods, the API Explorer entry and the MCP tool. There is no second place to fix a wrong description.

See Capabilities for the whole contract.

Replacing another app's capability

A capability entry's type is define (this app authors the contract) or implement (this app fulfils a contract another app defined). implement is the mechanism by which a tenant swaps out one operation — a stock availability call answered from an ERP instead of from the inventories app.

2. Deploy

revenexx deploy app

One command runs the whole path: register if new, upload, build, publish, install. See App lifecycle for the flags.

3. Publish and install run on every version

It looks redundant to publish and install a version of an app the tenant already has. It is not:

The same applies to a cockpit.json change that names a new endpoint: the manifest is read per request, so the screen changes as soon as the deployment is active — but the capability behind its button only exists once the install has written the route. A manifest that ships ahead of its install gives an operator a button that 404s.

4. What the merchant sees

Once installed, the studio reads your cockpit.json alongside every other installed app's and merges the declarations: your navigation entries land in their group at their position, your views become live routes under /commerce, your widgets become available on the dashboard.

Nothing else is needed. The same file that rendered in your preview renders in the Cockpit, because the preview runs the same module.

Where the partner path stops today

What that means in practice

Fully available to you today:

• Writing cockpit.json, schema.json, manifest.json and manifest.capabilities.json against the public JSON Schemas.
• Rendering the whole surface locally with the devkit — every list, detail, form and widget, with mock data from your schema.
• Running your function locally against a simulated gateway, including cross-app calls, in the devkit's /functions console.
• Iterating until the manifest is correct, and handing over something already right.

Needs revenexx involvement today:

• Getting a first version registered, published and installed on a tenant.

Talk to us about the install rather than budgeting for a self-serve rollout. The manifest work is entirely yours and entirely portable — nothing about the local loop is throwaway.

Two other things marked unexercised

Both are covered where they belong, and repeated here so a plan does not depend on either:

Everything else on these pages is in production use across the thirteen commerce apps.

Where to go next

• App lifecycle — scaffold, deploy, version and upgrade.
• Capabilities — define, implement, routes and the published contract.
• Manifest reference — the rest of manifest.json.
• Billing and events — the Marketplace listing.
• Preview locally — the loop that is available now.