API and CLI

Create a publishing token

Publishing tokens live on the profile settings page. Tokens are shown once, stored hashed, scoped narrowly, and must expire within a bounded lifetime.

• Treat the raw token like a password. Store it in a secure secret manager or local env file, not in source control.
• If a token leaks, revoke it and create a new one.
• Use separate tokens for separate tools or agents so revocation stays targeted.
• Prefer shorter-lived tokens for local automation and agents.

Project ingestion API

The first ingestion route is POST /api/projects. It accepts the same project fields as the app form and uses the same access model for source, install, docs, and visibility.

There is also a PATCH /api/projects/:id route for updating owned projects through the same secure token model.

{
  "title": "PairSend",
  "tagline": "Encrypted handoff between two devices.",
  "description": "Short project overview and current direction.",
  "tags": ["file transfer", "webrtc"],
  "stack": ["Next.js", "Cloudflare Workers"],
  "visibility": "unlisted",
  "sourceAccess": "none",
  "distributionAccess": "none",
  "coverStyle": "gradient-4"
}

Local CLI

The local CLI is a thin client on top of the secure API. It is intended for agents and power users, not as a second business-logic layer.

Use publish to create a project from a local folder. Use update when you need to refresh docs, visuals, or metadata on an existing project.

Prefer VICODE_TOKEN or --token at runtime. The CLI only stores a plaintext token if you explicitly opt into insecure local storage.

npm run vicode -- login --api https://your-vicode-host
set VICODE_TOKEN=vct_xxx
npm run vicode -- publish --dir D:\Projects\MyProject

Updating an existing project

If an agent already knows the project slug or id, it can update the owned project directly through the CLI or PATCH route.

update is intentionally sparse. It only sends the fields you pass explicitly, plus docs content when you opt into --sync-docs.

npm run vicode -- update --project pairsend --dir D:\Projects\PairSend\main --sync-docs

Secure publishing defaults

The publishing API does not assume every project is public-source or installable. Source access and distribution access are explicit fields, and external URLs are validated as secure https links by default.

That keeps the public project page honest: a private repo stays private, a showcase-only project does not pretend to be installable, and a public package can opt into install or download surfaces when it is actually ready.