Skip to main content
REST surface for two operator-facing concerns: the persisted Clawboo settings (/api/settings, the upstream OpenClaw Gateway URL + token, plus a first-run dismiss timestamp) and the boot probe (/api/health + /api/health/recheck, a fresh-install health check that backs the System Health view and answers a one-field liveness query).
The raw gateway token is never returned by any route here. GET /api/settings exposes only hasToken: boolean; the same-origin proxy injects the upstream token server-side, so the browser never needs the credential.
All POST routes read a JSON body parsed by express.json({ limit: '2mb' }). Every error response is the standard { error: string } envelope (the health routes’ 500 path uses { ok: false, error }, see below).

Routes


GET /api/settings

Returns the current persisted settings from ~/.clawboo/settings.json (via loadSettings()). The gateway token is redacted to a presence boolean.
  • Path/query params: none.
  • Request body: none.

Responses

200 OK: the persisted settings, token-redacted:
500 Internal Server Error: settings could not be loaded:

Example


POST /api/settings

Persists settings with a partial update: only fields present in the body are written; an omitted field is left unchanged (so a dismiss-only POST does not clear the gateway URL). When gatewayUrl or gatewayToken is present, the server-side AgentSource registry is reconnected best-effort (non-blocking, errors swallowed).
  • Path/query params: none.
  • Request body:
gatewayUrl is validated to a ws:/wss: scheme before it is stored, because the same-origin proxy later dials it (new WebSocket(upstreamUrl)). A non-websocket target (http/file/javascript) is rejected. The host is intentionally not restricted; a remote gateway is a supported choice.

Responses

200 OK: settings saved:
400 Bad Request: the body is missing or not an object:
400 Bad Request: gatewayUrl is present, non-empty, and not a ws:/wss: URL:
500 Internal Server Error: saving failed:

Example


GET /api/health

Returns the latest BootReport. The boot probe runs once at server start and the result is cached; if no report exists yet (a pre-boot request), the handler computes one on demand so the endpoint is always answerable; this is the one liveness surface that works with the Gateway down. The ok field (= no fatal checks) is the one-field summary a simple liveness probe can read.
  • Path/query params: none.
  • Request body: none.

Responses

200 OK: the boot report (see The BootReport shape below). Date fields serialize to ISO strings via JSON.
The response is passed through redactObject before send (the same redact-on-display applied to obs/audit/tools): a credential-shaped substring landing in any check message/detail is masked, while readable paths and config stay intact.
500 Internal Server Error: only on the pre-boot path, if computing the report throws:

Example


POST /api/health/recheck

Recomputes the boot report fresh (the “Re-run probe” action after the user fixes a problem). Same response shape as GET /api/health.
  • Path/query params: none.
  • Request body: none (ignored).

Responses

200 OK: the freshly-computed boot report, redacted (identical shape to GET /api/health). 500 Internal Server Error: if recomputing throws:

Example


The BootReport shape

GET /api/health and POST /api/health/recheck both return this structure (with ok prepended). It is the output of the boot probe (runBootProbe in apps/web/server/lib/bootProbe.ts).

Fatal vs degraded

Almost every check degrades (the server keeps running and the UI shows a banner) rather than being fatal. Three failures are fatal: clawbooHomeWritable, databaseIntegrity and databaseSchema, because nothing works without them. A fatal check’s detail says what to do; resetting ~/.clawboo and re-running the onboarding wizard is the last resort. ok = report.fatal.length === 0. A degraded-but-not-fatal install returns ok: true with a non-empty degraded[].

The checks (in run order)

config (production-defaults posture)

config surfaces the shipped defaults so a user or bug report can see what the install runs with. The values come from apps/web/server/lib/defaults.ts:

Error envelope

Every error response on these routes is the standard envelope { error: string } (/api/settings), except the health routes, which return { ok: false, error: string } on their 500 path (their success body always carries ok).

See also

Last modified on August 10, 2026