Dashboard and CLI login
Covers 5 API operations in the auth category.
| Method | Path | Description |
|---|---|---|
| POST | /v1/auth/dev/login | Sign in with the dev login method |
| GET | /v1/auth/github/start | Start GitHub OAuth |
| GET | /v1/auth/github/callback | GitHub OAuth callback |
| GET | /v1/config | Names for this deployment |
| GET | /v1/me | The current user and their organizations |
POST /v1/auth/dev/login
This is a local-only sign-in method. It serves the same purpose as GitHub OAuth, but
without an external auth round trip (docs/local-mvp.md §1). In production, this route is not
registered — it only exists on servers where RUNLOT_ENABLE_DEV_AUTH is on.
Calling it again with the same subject returns the same user — it would be unusable if
a new account were created every time you lost a token locally.
operationId devLogin
Request body: application/json · object
| Status code | Description | Response body |
|---|---|---|
| 200 | Session token | Session |
| 400 | — | — |
GET /v1/auth/github/start
redirect is the client callback to return to, with the token carried as a
fragment, after login finishes (https://dash.runlot.io/login/callback). It must
match a prefix in the server's allowlist (RUNLOT_GITHUB_REDIRECTS, defaulting
to RUNLOT_PUBLIC_URL). This sends a 302 to the GitHub authorize page. Since
the browser follows this path, client libraries don't call it — open it with
window.location.
operationId githubStart
| Parameter | Location | Required | Type | Description |
|---|---|---|---|---|
redirect | query | Yes | string | — |
| Status code | Description | Response body |
|---|---|---|
| 302 | to GitHub authorize | — |
| 400 | — | — |
GET /v1/auth/github/callback
This path is the GitHub app's Authorization callback URL. It exchanges
the code for a session, then issues a 302 to redirect — on success,
#token=…&expiresAt=…&userId=…&subject=…; on failure,
#error=<code>&message=…. It uses a fragment so the token is not
recorded in server logs or the Referer header.
operationId githubCallback
| Parameter | Location | Required | Type | Description |
|---|---|---|---|---|
code | query | No | string | — |
state | query | Yes | string | — |
error | query | No | string | — |
| Status code | Description | Response body |
|---|---|---|
| 302 | to the client callback | — |
| 400 | — | — |
GET /v1/config
This is where the dashboard finds out which deployment it is attached to
(docs/environments.md §3.2). The dashboard is a single static build, so it
has no way to know a different value per deployment, and the page had it
hardcoded as a string — once there are two environments, the dev page points
to production's address, and that guidance looks plausible enough that no
test catches it.
No authentication: the login page also has a documentation link. All that appears here are names already listed on the landing page.
Feature on/off state is not here — billing, storage, and email each have their own endpoints that report their own state.
operationId getSiteConfig
| Status code | Description | Response body |
|---|---|---|
| 200 | Names for the deployment | object |
GET /v1/me
The current user and their organizations
operationId getMe
| Status code | Description | Response body |
|---|---|---|
| 200 | Users | object |
| 401 | — | — |