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. Where the platform reviews releases, publish and install wait until the release is approved, and the command stops before them until then (see When the release waits for approval).

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.

Doing it without revenexx

revenexx deploy app takes a first version from nothing to installed on your own tenant, with no step on our side: it creates the app if it does not exist, uploads and builds the source, publishes it to the Marketplace and installs it. Every build of an archive that contains a manifest.json validates it against the public schemas and registers the version (a Git build does this only on the app's production branch), and a build whose manifest is invalid fails rather than producing something that cannot be published. The quick start walks the whole path.

The same steps are available over REST — POST /v1/apps, POST /v1/apps/{functionId}/deployments, POST /v1/apps/{functionId}/publish, then the install — if you drive them from your own pipeline. Every route is listed in Apps API. Two things to know if you go that way:

• The route descriptions lag the platform. POST /v1/apps and the deployments route still say manifest validation is deferred to a later phase. It is not: the build does it.
• Publish needs a ready deployment. Publishing before the build has finished answers 400 and tells you to deploy first. Poll the deployment until it is ready, as the CLI does.

Your vendor namespace belongs to your tenant: a manifest whose vendor another tenant already owns is refused at validation.

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.