runlot
ReferenceAPI

Dashboard and CLI login

Covers 5 API operations in the auth category.

MethodPathDescription
POST/v1/auth/dev/loginSign in with the dev login method
GET/v1/auth/github/startStart GitHub OAuth
GET/v1/auth/github/callbackGitHub OAuth callback
GET/v1/configNames for this deployment
GET/v1/meThe 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 codeDescriptionResponse body
200Session tokenSession
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

ParameterLocationRequiredTypeDescription
redirectqueryYesstring
Status codeDescriptionResponse body
302to 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

ParameterLocationRequiredTypeDescription
codequeryNostring
statequeryYesstring
errorqueryNostring
Status codeDescriptionResponse body
302to 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 codeDescriptionResponse body
200Names for the deploymentobject

GET /v1/me

The current user and their organizations

operationId getMe

Status codeDescriptionResponse body
200Usersobject
401

On this page