// docs

REST API

Trigger scripts, runbooks, installers, and S.E.N.T.R.I prompts — and schedule them — from any tool that can make an HTTP request.

Base URL & scope

The control API is hosted by the automation service at:

Base URL
https://127.0.0.1:5001/api/v1

HTTPS by default

The API serves HTTPS on port 5001 out of the box with a self-signed certificate. Import the ServerEngine-CA to trust it system-wide, or skip verification for loopback testing — -k (curl), -SkipCertificateCheck (PowerShell 7+), verify=False (Python requests).

Loopback only

The control API binds to 127.0.0.1 and is not exposed to the network — because it can start jobs. To reach it from another machine, front it with your own reverse proxy or VPN. Never expose it directly.

Authentication

Every request needs a Bearer token. ServerEngine generates one for you — find it on the API tab in Settings (a value beginning with se_) and copy it with one click. You can regenerate it at any time; the service and console switch to the new token immediately, and any client using the old one must be updated.

Authorization header
Authorization: Bearer se_your-token-here

Endpoints

Method & pathPurpose
GET /healthService status, license, and running/queued job counts.
POST /jobsRun a script, runbook, installer, or S.E.N.T.R.I prompt now. Returns the job ID(s).
GET /jobsList jobs and their status.
GET /jobs/<id>/outputRead a job's console output (supports a byte offset).
POST /jobs/<id>/restartRetry a job.
DELETE /jobs/<id>Cancel and remove a job.
GET /schedulesList schedules.
PUT /schedules/<id>Create or update a schedule.
DELETE /schedules/<id>Remove a schedule.
GET /logs?tail=NRead the most recent log lines.
GET /inventoryList hosts, groups, and bundles (names only).

Running a job

POST /jobs takes a small JSON body. target and run are required; a group target expands to one job per host.

FieldValue
targetA host FQDN, a group name, or "(This Computer)".
runA script, .runbook, or installer name — or, for a prompt, the instruction itself.
typeOptional — Script, Runbook, Installer, or Prompt (inferred from the name if omitted).
parametersOptional — dynamic values as [VAR:name,VAL:value] tokens.

The parameters string uses the same substitution as runbooks: each VAR token is replaced with its VAL in the script before it runs.

Running a S.E.N.T.R.I prompt

Set type to Prompt and put the instruction in run. The service runs the agent headlessly against target, and the conversation and every action land in the Logs under the returned job ID.

POST /jobs — hand the agent a goal
{
  "target": "srv01.demo.local",
  "type": "Prompt",
  "run": "Check disk space on C: and report anything under 15% free"
}

No approvals on an API-triggered prompt

Like a scheduled prompt, an API-triggered run is unattended — there is no one to accept or decline, so approval-required skills are skipped. The scope and your enabled skills are the boundary.

Copy-paste examples

The same ready-to-run samples you'll find in ServerEngine under Settings → API:

# ServerEngine v5 - jobs run through the ServerEngine service.
# Copy the API token from the app's API tab (Copy button). The control
# API serves HTTPS on 127.0.0.1:5001 by default (local only - use a
# reverse proxy of your choice for remote access). The certificate is
# self-signed: import the ServerEngine-CA to trust it, or on
# PowerShell 7+ add -SkipCertificateCheck to each call.
$token = "se_paste-your-token-here"
$base  = "https://127.0.0.1:5001/api/v1"

$headers = @{
    "Content-Type"  = "application/json"
    "Authorization" = "Bearer $token"
}

# --- Run a script, runbook or installer right now ---
$body = @{
    target     = "(This Computer)"   # host FQDN or group name
    run        = "myscript.ps1"      # script, .runbook or installer

    # dynamic parameters: every xTest1 in your script is
    # replaced with someText before it runs
    parameters = "[VAR:xTest1,VAL:someText][VAR:xTest2,VAL:more]"
} | ConvertTo-Json

$job = Invoke-RestMethod -Uri "$base/jobs" -Method POST -Headers $headers -Body $body
$id  = $job.jobIds[0]

# --- Wait for the job to finish, then print its console output ---
do {
    Start-Sleep -Seconds 2
    $state = (Invoke-RestMethod -Uri "$base/jobs" -Headers $headers) |
             Where-Object id -eq $id
} while ($state -and $state.status -notmatch "Completed|Failed")

(Invoke-RestMethod -Uri "$base/jobs/$id/output" -Headers $headers).output

# --- Or schedule it instead (creates a Windows Scheduled Task) ---
$sid  = [guid]::NewGuid().ToString("N")
$body = @{
    time    = (Get-Date).AddMinutes(5).ToString("HH:mm")
    date    = (Get-Date).ToString("yyyy.MM.dd, dddd",
              [Globalization.CultureInfo]::InvariantCulture)
    interval = "One time"  # or: Every (5m/15m/30m/1h/2h/3h/6h/12h),
                           # Daily (24h), Weekly (7 days), Monthly (28 days)
    target   = "(This Computer)"
    run      = "myscript.ps1"
    state    = "Enabled"
} | ConvertTo-Json
Invoke-RestMethod -Uri "$base/schedules/$sid" -Method PUT -Headers $headers -Body $body

Scheduling via the API

PUT /schedules/<id> creates or updates a schedule. Provide the time, date, interval, target, and what to run.

FieldFormat
time24-hour time, e.g. 14:30.
datee.g. 2026.12.24, Thursday.
intervalOne time · Every (5m…12h) · Daily (24h) · Weekly (7 days) · Monthly (28 days).
state"Enabled" or "Disabled".

Automate from your stack

  1. 1

    Monitoring webhooks

    Have your monitoring tool POST a remediation job when an alert fires.
  2. 2

    CI/CD

    Kick off a deployment runbook from a pipeline step after a successful build.
  3. 3

    Workflow tools

    Chain ServerEngine jobs into n8n, Zapier, or a custom script — anything that speaks HTTP. A Prompt job lets those tools hand a goal to the agent instead of a fixed script, giving your workflow full reach into your local Windows endpoints.