Beta documentation

Quickstart

Time to first live screen should be under ten minutes. If it is not, tell us.

Download the latest DisplayOps image from the portal under Displays → Pair a display. The SHA-256 checksum is shown next to the download; verify it before flashing.
Write it to a microSD card with Raspberry Pi Imager (Use custom, then pick the .img.xz). In the advanced options you may preload Wi-Fi and, for troubleshooting, enable SSH; Ethernet needs nothing. Step-by-step instructions for Windows (Imager or Rufus), macOS and Linux are in the flashing guide.
Optional, zero-touch: on the pairing page choose Set up before flashing to download a displayops.conf with your Wi-Fi and an enrolment token, and copy it onto the bootfs drive after flashing. The screen joins Wi-Fi and appears in your organisation already paired; skip the next two steps.
Insert the card, connect HDMI and power. After about 40 seconds the screen shows a six-character pairing code and a QR code.
In the portal choose Pair a display, enter the code, and name the screen.
Assign content. The screen updates within a few seconds.

Content types

Website: a URL. The player opens it full screen; a timed reload, if the page needs one, is the display's Auto refresh setting. For Grafana and similar dashboards, see the guide to showing a private Grafana dashboard without a login. For a page behind HTTP basic or digest authentication, tick The page asks for a username and password on the content item; the password is stored encrypted and the screen answers the browser's prompt itself. Never put credentials in the address. See the HTTP authentication guide.
Image: PNG, JPEG, or WebP. Uploaded once, cached on every device that shows it.
Video: MP4 (H.264). Loops by default. Cached on the device for offline playback.
Slideshow: an ordered list of websites and images with a per-item duration.
Message: large text with foreground and background colours. Useful for overrides and emergencies.

API

Base URL https://app.simpledisplayops.com/api/v1. Authenticate with an API key from Developers in the portal, sent as Authorization: Bearer sdo_…. Everything the portal does, the API does.

# List displays
curl https://app.simpledisplayops.com/api/v1/displays -H "Authorization: Bearer $SDO_KEY"

# Point a display at a URL
curl -X POST https://app.simpledisplayops.com/api/v1/displays/DISPLAY_ID/content \
  -H "Authorization: Bearer $SDO_KEY" -H "Content-Type: application/json" \
  -d '{"type":"website","url":"https://status.example.com"}'

# Send a command: refresh | restart_player | reboot | screenshot
curl -X POST https://app.simpledisplayops.com/api/v1/displays/DISPLAY_ID/commands \
  -H "Authorization: Bearer $SDO_KEY" -H "Content-Type: application/json" \
  -d '{"type":"refresh"}'

Webhooks

display.online, display.offline
display.health (temperature, storage, under-voltage, browser restarts)
display.command.completed
display.screenshot

Security model

Each device receives a unique key pair at pairing time. There is no fleet-wide credential.
SSH is off on every screen until an admin enables it from the display page with a public key. Enabling is key-only (password logins are switched off on the device), scoped to the screen's admin user, recorded in the activity log and can send a security notification; disabling removes the keys again.
Commands are authenticated, authorised, timestamped, and replay-resistant.
TLS everywhere. Session secrets for dashboards are encrypted at rest.
Agent updates are signed and roll back automatically if the new version does not check in.
Operating-system security updates (Debian security and Raspberry Pi repositories only) are applied by the agent inside a maintenance window you choose, with an optional reboot in that window. You can also check or apply per screen, or roll a group out in waves with a failure threshold. Every apply is in the activity log and can notify you.
No general remote shell. Support diagnostics are delivered as a downloadable bundle.