Apps API

The Apps API creates and runs the code behind an app: it creates apps, uploads and activates deployments (versions), runs executions, manages environment variables, publishes an app to the Marketplace and installs Marketplace apps on your tenant, and reads usage. It is for developers who drive those steps from their own pipeline. For a first version, use the CLI: revenexx deploy app does every step in one command. Over REST the usual order is create the app, upload a deployment, activate it, run it, then publish it and install it; the steps are walked through in From manifest to installed.

Before you call it

• Tenant header. Every call needs X-Revenexx-Tenant. Without it the gateway answers 400 before it checks your credential.
• Scope. An API key must carry the apps scope (or *). Without it the call fails with 403 and api key missing scope: apps. A key for another tenant answers 403 with api key not valid for this tenant. A Bearer token is checked for tenant membership instead (403 with not a member of this tenant).
• Errors. Gateway errors have the shape {error, code, message}. Errors from the platform itself are passed through as {message, code, type, version}, where code is the HTTP status as a number.
• Array query parameters. Repeat the parameter once per value, for example ?runtimes=…&runtimes=…. The list operations for apps, deployments and executions take queries this way: filters, paging and ordering, each value a JSON object such as {"method":"limit","values":[25]}.

See Authentication and API keys for how to get and send a credential.

Apps

• POST /v1/apps requires functionId, name and runtime.
• PUT /v1/apps/{functionId} requires name.

Deployments

• GET …/download takes type: source or output.
• POST …/deployments is multipart/form-data. It requires code (your source directory as a gzipped tar archive, .tar.gz, sent as the file part) and activate (activate the deployment when the build finishes).
• POST …/deployments/duplicate requires deploymentId.
• POST …/deployments/template requires repository, owner, rootDirectory, type and reference.
• POST …/deployments/vcs requires type and reference.
• PATCH …/deployment requires deploymentId.
• The build validates the app's manifest.json when the archive contains one. A Git deployment validates and activates only on the app's production branch; a build of another branch skips both. The operation descriptions in the API Explorer still say validation comes later; the build does it today.

Executions

• The execution body has no required fields. method is one of GET, POST, PUT, PATCH, DELETE, OPTIONS or HEAD (default POST). path defaults to /, body to an empty string, and async to false. Use them to call the app as if from an HTTP request.

Variables

• POST …/variables requires key (up to 255 characters) and value (up to 8192 characters). The app reads them as environment variables at runtime.
• PUT …/variables/{variableId} requires key.
• A variable can be marked secret. A secret can be updated or deleted, but only the app itself can read it, during build and at runtime.

Marketplace and publishing

• POST …/marketplace/install requires owner and name.
• Publishing needs at least one ready deployment with a registered manifest (otherwise 400), and the manifest's type must be public: a private app answers 409.

Templates, runtimes and specifications

• useCases accepts starter, databases, ai, messaging, utilities, dev-tools and auth.

Usage

• range accepts 24h, 30d or 90d.