Generate daemon upgrade commands
The steps to replace a daemon's binary and restart it, per OS, plus the docker method. Like the install command, a pure builder over the daemon record.
User API key (Bearer scp_u_...). Create in Platform > API Keys.
In: header
Path Parameters
daemon ID
Response Body
application/json
application/json
curl -X GET "https://example.com/api/v1/daemons/497f6eca-6276-4993-bfeb-53cbbbba6f08/upgrade-command"{
"meta": {
"api_version": 1,
"server_version": "0.18.1"
},
"success": true,
"data": {
"docker": {
"pinned_image": "string",
"pull": "string",
"config_copy": "string"
},
"freebsd": [
{
"command": "string",
"type": "Download"
}
],
"legacy_service_name": true,
"linux": [
{
"command": "string",
"type": "Download"
}
],
"macos": [
{
"command": "string",
"type": "Download"
}
],
"windows": [
{
"command": "string",
"type": "Download"
}
]
},
"error": "string"
}{
"meta": {
"api_version": 1,
"server_version": "0.18.1"
},
"success": true,
"code": "string",
"error": "string",
"params": {
"property1": null,
"property2": null
}
}Generate daemon install command
A pure, idempotent builder — it never mints or persists anything. The api key in an `install` or `rekey` 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 `rekey` — whether the daemon has checked in (`last_seen`) to decide whether the command names the existing install it re-keys. An `install` command reads the same before and after the daemon's first handshake.
Get all daemons
Returns all daemons accessible to the user. Supports pagination via `limit` and `offset` query parameters, and ordering via `group_by`, `order_by`, and `order_direction`.