http://<scout-host>:6556. Scripts can manage jobs and trigger backups without opening a browser. The UI reads the same backend state, so API changes also appear there.
Use the Station API to manage stored snapshots and mint Station tokens. Each app has its own sign-in session.
Authenticate
Management endpoints accept Scout’s session cookie,three_to_one_go_scout_session, or a scoped automation token. A Station token does not authenticate these endpoints. Session in the tables means a signed-in account; Admin also requires admin access. Accounts are intended for one operator.
The examples use a POSIX shell and curl; the settings example also uses jq. Replace password placeholders with your own values. Use your HTTPS address for remote access; see Session cookies over HTTPS.
Sign in and save the cookie for subsequent calls:
status and user. If user.must_change_password is true, change the password before calling other management endpoints. This is required on the first admin sign-in, even with a custom INITIAL_ADMIN_PASSWORD:
Automation tokens
For scripts or an external MCP adapter, open Admin → Users & Access → Automation Tokens. Choose a name, expiry, and permissions; copy the returned token once. The token belongs to the existing operator account. It is valid only in the app that issued it, and it stops working if revoked, expired, or its owner no longer has admin access or must change their password.
Select multiple scopes when needed.
read excludes settings and secret-bearing key, hook, certificate, and notification endpoints. manage is broad: it includes settings, hooks, keys where available, deletion, and Station token management where available. There is no per-job or per-instance ownership model.
Creating, listing, and revoking automation tokens requires an admin session cookie:
GET /api/session/me also accepts an automation token and returns its metadata under automation_token. The endpoint tables below describe session access; automation tokens additionally require the applicable scope. An invalid bearer token returns 401 even if a valid cookie is also present.
Browser writes from another origin are rejected with 403. Serve the UI through the same origin as its API, and preserve the request host through a reverse proxy. Ordinary curl requests without browser origin headers continue to work.
Status, schedule, and settings
Run a backup cycle
queued means the request was accepted, not that a backup completed. Poll /api/status for scheduler.state, run_now_requested, and the cycle timestamps, and /api/directories for each job’s state.last_status and error details. already_running means an operation is in progress; it does not schedule an additional run. These endpoints don’t return an operation ID.
A normal cycle uses the existing change detection: file paths and sizes plus empty folder paths. Same-size edits require a forced fresh backup.
Change settings
POST /api/settings takes the settings object itself, without a surrounding settings property. It replaces the submitted settings; omitted fields fall back to defaults and environment overrides. Read the current settings, change the desired fields, then submit the full object:
scout_credential in JSON. Settings and status responses can contain that token, so keep them out of public logs. Read current values again before a later update rather than replaying an old settings file.
Jobs and files
relative_path is relative to Scout’s scan root, using / between folders. Use . for the scan root. Job actions identify the folder path, not the job name used on Station.
Create or update a job
The folder must already exist under the scan root.config uses the same fields as .upload_dir, and saving replaces the marker’s configuration:
config uses the job defaults. The returned directory.config_error reports configuration problems; inspect it rather than treating HTTP success alone as proof that the job is valid.
Browse a folder with query encoding:
Force a fresh backup
Force upload can reuse a staged archive. To include same-size edits or new exclusions when an archive is already staged, wait for active work to finish, clear the staged backup, then force the upload:Restore
All restore actions require admin access. They restore whole snapshots and replace destination files with matching paths; files absent from the snapshot are left untouched.
For a local job restore, omit
fingerprint or use an empty string for the latest snapshot. An 8- or 64-character lowercase hex fingerprint selects the newest matching snapshot from the current Scout instance:
/api/recovery/restore to write the files. These calls wait for their work to finish; a restore can also return status: "already_running" without restoring anything.
For a request created through Station’s API, relative_path is a single folder name directly under the scan root and defaults to the request’s job name. When restoring from another Scout instance, supply the original snapshot’s Scout key in encryption_key. It is used for that restore and does not replace this Scout’s own key. Requests expire after one hour. See Restore requests for retries and destination rules.
Scout key
The route names are retained for compatibility; the user-facing name is Scout key. Keep keys private. Before rotating, read Rotate the key: old snapshots still need the old key, and local job restores use the current key.
Notifications, hooks, and certificates
JSON writes to these settings endpoints replace the listed fields within their section. Include every value you want to keep. File uploads use multipart form data instead of JSON.
For example:
Accounts
Errors and automation
Send JSON bodies withContent-Type: application/json. API errors generally return a detail property:
Check both the HTTP status and the response’s operation
status. Don’t repeatedly log in for every API call, and don’t assume a queued backup has completed. Poll status at a reasonable interval and avoid blindly retrying restore or key-rotation calls.