Nuved API

The API behind console.nuved.io. Everything the console does is here, and the nuved CLI and coding agents use the same endpoints with a token. Below is every one of them; the machine-readable description is /openapi.json.

The four addresses

AddressWhat you do there
console.nuved.ioSign in, name your organization, top up, create projects, mint tokens.
api.nuved.ioThis API: the same things, for the CLI and for anything you write.
kube.nuved.ioThe Kubernetes API for your projects, filtered to what your credential owns. Point kubectl at it with the kubeconfig from /v1/projects/{name}/kubeconfig and use the upstream Kubernetes reference for its endpoints; they are not described here.
<service>-<project>.nuved.ioWhere your own services answer, once you deploy something a route points at.

A typical session

  1. Sign in — in a browser at /login, or with nuved login, which runs the device flow and posts the result to POST /auth/cli.
  2. Top up — POST /topup from the console; the balance is what everything spends.
  3. Create a project with caps — POST /v1/projects with cpu, mem and how many services.
  4. Mint an agent token for it — POST /v1/tokens; it is shown once and reaches that project only.
  5. Download the kubeconfig and deploy — GET /v1/projects/{name}/kubeconfig, then kubectl as usual.

Credentials

A session (nvd_sess_…) is a person signed in: it speaks for the whole organization, including money, caps and credentials. An agent token (nvd_agent_…) is minted for one project: it can deploy, read and fetch its own kubeconfig, and nothing else. Both travel the same way, as Authorization: Bearer <token>; the console sends its session in a cookie instead. Every refusal is {"error": "a sentence"}.