Documentation & API Reference

Quickstart

Mint an API token from Dashboard → API Tokens. Tokens are prefixed lvse_and are shown once at creation time — copy them straight into your secret store. Then verify it works:

curl -H "Authorization: Bearer lvse_…" \
     https://launchverse.app/api/v1/me

# {
#   "team":   { "id": "…", "name": "Acme", "plan_tier": "Pro" },
#   "scopes": ["read", "write", "deploy"],
#   "tokenId": "…"
# }

Every endpoint below is documented as plain HTTP — you can call it from any language. The dashboard itself uses the same routes.

Authentication

The public API uses bearer tokens. Pass them on every request in the Authorization header:

Authorization: Bearer lvse_<token>

• Tokens are scoped to a single team. Switching teams in the dashboard does not affect API calls.
• Three scopes: read, write, deploy. You choose the scopes when you mint the token.
• Tokens can have an expiry date. Expired tokens fail with HTTP 401.
• The dashboard's own session uses cookie-based auth and is not exposed publicly.

Failed authentication always returns 401 Unauthorized with a JSON body of { "error": "..." }. Insufficient scope returns 403 Forbidden.

Endpoints

All requests are JSON. The base URL is https://launchverse.app.

Routes prefixed /api/v1/ are stable; non-versioned routes are used by the dashboard and may change shape between releases.

Deployment workflow

1. Push your code to GitHub. Connect the repository through the dashboard or via the GitHub App, then branch and PR like normal.
2. A build slot is reserved.Every deploy passes through one admission gate that checks your concurrent-deploy cap, monthly build-minute quota, and the cluster's available CPU and memory. If the cluster is full, your build joins a FIFO queue and starts as soon as capacity frees up.
3. Framework detection runs.Next.js, Remix, Vite, plain Node, Python, Go, Rust and more — we detect, install dependencies and build with the right tool for your stack.
4. Container starts. Your project runs in an isolated container with the CPU and memory budget your plan allows. Logs stream to the dashboard live.
5. TLS is issued and DNS is wired. A .launchverse.app preview URL is available immediately. Custom domains add a CNAME / A record and are issued certificates automatically.
6. Build minutes are recorded.Billing is from the moment the build actually starts — queue time is free.

Every step is observable through the per-project dashboard, the Build logs view, and the analytics page.

Webhooks

GitHub

Connect the LaunchVerse GitHub App once and every push or PR automatically triggers a build. Inbound webhooks are verified with HMAC-SHA256 against a per-install secret, then deduplicated by GitHub's delivery ID — if a delivery is retried (network blip, gateway timeout) we acknowledge with 200 instead of triggering a duplicate build.

Deploy hook

Each project has a unique URL of the form /api/deploy/hook/<token>. POST to it from any external system to kick off a build:

curl -X POST https://launchverse.app/api/deploy/hook/<token>

Engine events

Build status transitions (Queued, Building, Deploying, Ready, Failed, Canceled) are pushed to the dashboard in real time over the LaunchVerse Realtime channel. Notifications fan out to teammates with guaranteed-once delivery.

Resource schemas

Every JSON response uses these top-level shapes. Optional fields are marked with ?.

{
  id: string,                  // uuid
  name: string,
  status: "Live" | "Deploying" | "Building" | "Failed" | "Stopped" | "Broken",
  fqdn: string,                // comma-separated domain list
  framework: string,           // "next", "remix", "vite", "node", …
  branch: string,
  github_repo: string,
  team_id: string,
  cpu_limit?: string,          // e.g. "0.5", "2"
  memory_limit?: string,       // e.g. "512m", "2g"
  pr_previews_enabled: boolean,
  created_at: string           // ISO 8601
}

{
  id: string,
  project_id: string,
  status: "Queued" | "Building" | "Deploying" | "Ready" | "Failed" | "Canceled" | "Skipped",
  trigger_source: "manual" | "push" | "pull_request" | "webhook",
  is_preview: boolean,
  pull_request_id?: number,
  branch?: string,
  commit_hash?: string,
  commit_message?: string,
  preview_url?: string,
  build_started_at?: string,
  build_finished_at?: string
}

{
  id: string,
  project_id: string,
  domain: string,                  // "app.example.com"
  verified: boolean,
  ssl_issued: boolean,
  dns_record_type: "A" | "CNAME",
  dns_record_value: string,
  created_at: string
}

{
  id: string,
  team_id: string,
  engine: "postgres" | "mysql" | "redis",
  version: string,
  status: "Provisioning" | "Running" | "Stopped" | "Failed",
  created_at: string
  // Credentials are returned only via /api/databases/[id]/credentials
}

Domains & SSL

Every project gets a free .launchverse.app URL. Custom domains follow the standard CNAME / A-record pattern:

• Subdomain (CNAME). Point your DNS at the CNAME shown on the Domains page (looks like edge.launchverse.app).
• Apex domain (A record). Point your A record at the IP shown on the Domains page.
• TLS certificates are issued automatically through Let's Encrypt and renewed before expiry. Wildcard certificates are available on Pro and Enterprise.
• HSTS is enabled on launchverse.app and on every custom domain by default.

Plans & quotas

Every plan caps four dimensions: concurrent builds, monthly build-minutes, per-container CPU, and per-container memory. Admission control rejects requests that exceed your tier with a clean rate-limit response — no silently truncated resources.

Full plan comparison and pricing is on the Pricing page. The cluster is shared fairly — each plan has a guaranteed share so a Free workload can never starve a paid team.