Email install command to current user
User API key (Bearer scp_u_...). Create in Platform > API Keys.
In: header
Request Body
application/json
The install command to send, exactly as shown in the UI.
Operating system the command targets, used to pick the email wording.
"linux" | "macos" | "windows" | "freebsd"Response Body
application/json
application/json
curl -X POST "https://app.scanopy.net/api/v1/daemons/email-install-command" \ -H "Content-Type: application/json" \ -d '{ "install_command": "string", "os": "linux" }'{
"meta": {
"api_version": 1,
"server_version": "0.17.8"
},
"success": true,
"data": {},
"error": "string"
}{
"meta": {
"api_version": 1,
"server_version": "0.17.8"
},
"success": true,
"code": "string",
"error": "string",
"params": {
"property1": null,
"property2": null
}
}Bulk delete daemons
Previous Page
Provision a daemon, or re-provision an existing one
Creates a daemon record on the server before the daemon is installed and mints an API key bound to it 1:1. Returns the daemon record and that key, which is shown only once and must be configured on the daemon. When `daemon_id` is supplied the existing record is reused instead of creating a new one, giving a legacy daemon (one with no bound key) a pathway to a dedicated key without losing its host, discovery jobs, or history. Re-provisioning always mints a fresh key. Install commands are not built here — fetch them from the install-command endpoint, which builds them idempotently and fills in the key this returns. That keeps a display-only regenerate (an OS switch, an advanced-setting change) from re-minting the key.