API#

A signed HTTP API that controls the box’s services. Each service gets its own path namespace - DayZ lives under /dayz/*. Every call must be signed. Every action comes from a fixed allowlist - there is no arbitrary-command path. The table below is the full set.

Connect#

Addresshttps://api.cytonicmushroom.ddns.net
AuthHMAC-SHA256 signature on every request
AccessBy shared secret - ask the host

Actions#

Trigger one with POST /dayz/<action> - grouped actions with POST /dayz/<group>/<action>.

ActionWhat it doesDestructive?
statusserver info: uptime, players, map, mods, next restartno
playersonline player count + rosterno
positionslive player map positions, anonymized to coordinates onlyno
missionsinstalled missions - the candidates a mapchange can switch tono
logs/files / logs/readlist every log file / read any slice - engine noise pre-filteredno
configs/*read allowlisted config files - replace the editable ones (with rollback)no
terrain/*baked heightmap lookup - terrain height at world X/Zno
broadcastin-game message to all playersno
startstart the serverno
restart / stoprestart or stop the serveryes
mapchangeswitch mission and restartyes
updatequeue a game update for the next restart (arms it - does not restart now)no
update/statusinstalled vs latest build, whether one is queued, and the last update resultno
update/cancelcancel a queued updateno

Host load is a root endpoint, not a /dayz action (it’s about the whole box): POST /sysload - CPU, memory, disk, plus the game server’s own footprint. Signed like the actions above.

POST /whoami is another root endpoint: it returns the calling key’s own identity, scope (full or observe), and namespaces. An access-aware UI reads it to show operator vs read-only controls instead of probing with a write it may not be allowed to make.

Calling it#

Sign the exact request body with HMAC-SHA256. Send the signature in X-Signature-256:

body='{"message":"Server restarting in 5 minutes"}'
sig=$(printf '%s' "$body" | openssl dgst -sha256 -hmac "$SECRET" -hex | sed 's/^.* //')
curl -sS https://api.cytonicmushroom.ddns.net/dayz/broadcast \
  -H "content-type: application/json" \
  -H "x-signature-256: sha256=$sig" \
  -d "$body"
  • Read actions also take query params: POST /dayz/logs/read?limit=200&type=adm (body wins on a clash). Destructive actions read the signed body only.

Some reads need no auth at all:

  • GET / - the whole-API index: every endpoint plus the action list.
  • GET /dayz/actions - the DayZ action allowlist with descriptions.
  • GET /openapi.json - the full OpenAPI spec.
  • GET /healthz - liveness probe.
  • GET /dayz/server-info - the current-server-info snapshot: state, uptime, players, map, mod list, next scheduled restart. Same payload as status, and only what the Steam server browser already publishes. This is what powers the server-info panel on this site.

Guardrails#

Hard to misuse by design:

  • Player guard - destructive actions refuse while anyone is online, or when the player count can’t be verified. Override with {"force": true} in the body.
  • Warning first - if anyone is connected, restart / stop / mapchange broadcast an in-game warning and wait 15 seconds before running.
  • Cooldowns - repeat an action too fast and you get a 409 with the seconds left to wait.
  • Rate limit - 30 requests per minute per IP, across everything.
  • Audited - every call is logged, accepted or rejected.

Updates#

Updates ride the reboot, they are not a separate disruptive event. update arms a flag; the next server start pulls the latest server build and mods before the engine comes up, then clears the flag. That next start can be the scheduled restart, a manual restart, or a forced one - any of them applies a queued update.

  • Nothing is kicked by update. Arming only sets the flag, so it is non-destructive. The disruption is the restart you choose to run, gated by the normal player guard.
  • Auto-check. The box checks Steam on a timer (default every 4 hours). If the installed build is behind, it arms the flag automatically and broadcasts a heads-up. The update then applies on the next restart with no API call at all.
  • Read the result. update/status reports the installed build, the latest known build, whether an update is queued, and the last applied update’s outcome plus a log tail. On a failure the server boots on the old build and the next auto-check re-arms.