Publish an application to the Pilot app store. The service generates, signs, and verifies an agent-first adapter for the application. Submissions are reviewed before appearing in the store.
Publishing Process
The publishing process requires describing an existing application. An agent-first adapter is then generated, signed, and verified. The submission is then reviewed by the Pilot team before it is listed in the app store.
A valid email is required for verification.
No application code is uploaded. The app's methods are described, and the adapter is built from that description.
Secrets are not collected. Operators supply keys at install time.
Every submission is reviewed before it appears in the store.
Email notifications are sent for submission confirmation and review status.
A publisher release agreement is signed before submission.
The steps are: describe the app, verify email, the adapter is built and verified, the team reviews, and the app goes live in the store.
Step 1: Email
An email address is required. It is used to send a submission confirmation and the review decision.
Step 2: Identity
Define the application's identity with the following fields:
App ID: A reverse-DNS identifier under the `io.pilot` namespace, using lowercase letters, digits, and hyphens.
Version: The application's version in SemVer format.
One-line description: A brief summary of what the app does.
Step 3: Backend
Define the application's backend type. Two types are supported:
HTTP API: For applications reachable over HTTP. An adapter is generated to forward each method to the API. A base URL and optional authentication headers are configured. A header value such as `${WEATHER_TOKEN}` is a secret placeholder: the operator who installs the app supplies it at install time from their environment or a local secrets file. It is never stored in the published app.
CLI: For command-line tools installed on the host. Each method runs a subprocess; `pilotctl appstore call` translates into `<cli> <args>`. The command must already be installed on the operator's host. The child runs with a scrubbed environment — only the listed variables (plus PATH/HOME/locale) are passed through. The app ships with a `proc.exec` grant scoped to exactly this command and installs guarded via the reviewed catalogue. The command is comma-separated argv (e.g. `gh` or `python, -m, tool`); each method appends its own args.
Step 4: Methods
Each method is a single call an agent can make. Each method requires a name, backend route, latency class, description, and parameters. The method name is prefixed with the app namespace, e.g. `app.search`.
Latency classes indicate typical call duration:
fast: under 5 seconds
med: up to 15 seconds
slow: up to 1 minute
For an HTTP API backend, each method specifies an HTTP verb and a path. The verb is one of GET, POST, PUT, PATCH, DELETE. The path is a backend route such as `/search` or `/items/{id}`; `{name}` placeholders insert a parameter into the path.
For a CLI backend, each method specifies its argv. Arguments are comma-separated argv appended to the command, using `${param}` to insert a payload field (e.g. `current, --lat, ${lat}`). A method may also append each parameter as `--name value` (params-as-flags). In passthrough mode the whole CLI is fronted: every subcommand is reachable and the caller supplies the argv, called as `{"args":["…"]}` with no baked arguments.
Each parameter has a name, a type (one of string, int, number, bool, object), a required flag, and a description.
For HTTP methods, each parameter also has an "In" (request-mapping location) that controls where the adapter reads it from when calling the backend:
query: `?name=value`, url-encoded. Default for GET.
path: fills `{name}` in the path, url-encoded (REST).
path_raw: fills `{name}` in the path unescaped — for URL-in-path APIs, e.g. a fetch/proxy that takes `GET /<rawurl>`.
body: JSON body field. Default for POST/PUT/PATCH.
header: sent as a request header.
When no location is chosen, the natural default for the verb is used: GET and DELETE default to query, and POST/PUT/PATCH default to body. A parameter mapped to path or path_raw requires a matching `{name}` placeholder in the path.
Step 5: Listing
Define how the application appears in the app store with the following fields:
Display name
License (SPDX identifier)
Tagline
App description (Markdown is supported)
Homepage
Source URL
Categories (comma-separated)
Keywords (comma-separated)
Step 6: Vendor
Provide information about the publisher with the following fields:
Vendor name
Vendor URL
How autonomous AI agents will use this app
List of all capabilities
Step 7: Review and Submit
The final step is to review all submission details and sign the Publisher Release Agreement.
The agreement confirms the publisher has the right to publish the app and grants Pilot Protocol a license to use the publisher's name and the app's name for listing and promotion.