Sign in
daemons

Generate daemon install command

A pure, idempotent builder — it never mints or persists anything. The api key in an install command is a placeholder (<API_KEY>) the caller substitutes from the plaintext it holds; a reconfigure command carries no key at all. Minting is a separate mutation (POST /provision), so regenerating a command here (advanced-setting change, OS switch, the Details reconfigure view) never rotates the daemon's key.

The server derives the exact command shape from the record: DaemonPoll vs ServerPoll for the flags, and — for install — whether the daemon has checked in (last_seen) to decide between a first-install and a minimal re-key command.

get/api/v1/daemons/{id}/install-command

Path parameters

idstring uuid required

daemon ID

Query parameters

purpose'install' | 'reconfigure' required

What the caller wants the command to do — the one axis that actually varies.

install brings a daemon up (or re-keys a legacy one): it carries the api-key placeholder, fetches the binary, and spells out the connectivity + advanced config. reconfigure adjusts an already-installed daemon in place: no key, no fetch, just the server-held connectivity — scanopy-daemon install layers it over the existing config.json. There is no third case: re-asserting the record's (correct) values on an installed daemon is harmless, so a first install and a re-key are the same command.

install (with the api-key placeholder) or reconfigure (credential-free).

log_levelstring nullable
log_filestring nullable
heartbeat_intervalinteger nullable
bind_addressstring nullable
allow_self_signed_certsboolean nullable
accept_invalid_scan_certsboolean nullable
interfacesstring nullable

Comma-separated interface names.

credential_refsstring nullable

Comma-separated credential/integration tokens (for the docker-compose env).

Response

Install command

errorstring nullable
successboolean required

Example response

{
  "meta": {
    "api_version": 1,
    "server_version": "0.17.5"
  }
}

Changes