API changelog | Screenly

Screenly 26.10.3: Screen reports on the API include hardware and software health

Fri, 09 Oct 2026 00:00:00 +0000

Screen reports on API v4.1 (GET /v4.1/screens/reports) now return much more of what a player reports about itself. From your own tools, you can watch a fleet for an SD card or a disk that’s starting to fail, keep an eye on temperatures, or check which model and software a player runs, without opening each screen in the dashboard.

Storage:

sd_card_health: errors on a Raspberry Pi’s SD card, and whether the card has turned read-only.
smart_disk_data: a S.M.A.R.T. summary of the SSD or NVMe drive on an x86 player, including its temperature, power-on hours, and how much of its life is used.
storage_info: the identity of a Raspberry Pi’s SD card: name, manufacturer, and date.
disk_usage: total, used, and free space on the player’s data storage, in bytes.
disk_stats: read and write counters for each disk since the player started.

Hardware:

sensors: temperature and other sensor readings, such as a Raspberry Pi’s chip temperature.
x86_stats: hardware temperatures on Screenly Player and Screenly Player Max.
mem_info: total, free, and available memory, in kB.
raspi_rev and raspi_serial: a Raspberry Pi’s board revision and serial number.

Software and security:

installed_snaps: every software package on the player, with its version.
device_model and validation_sets: the ScreenlyOS image a player runs, and the exact package versions it’s held to.
secure_boot, full_disk_encryption, and mtls_enabled: whether the player uses secure boot, an encrypted data partition, and a client certificate for its connection to Screenly.
is_wayland: whether the player draws through the newer display stack.

Display, network, and running state:

display_data: each connected display’s make, model, size, and supported resolutions.
screen_resolution: the resolution content is shown at.
bluetooth: on, off, or unknown. off also covers a player with no Bluetooth at all.
probe_diagnostics: the results of the player’s own network checks, refreshed about once a day.
player_uptime: seconds since the player’s content started, which restarts once a day.
local_time: the player’s clock when it sent the report.

Fields fill in from each player’s next report, and some apply only to certain hardware: a field a player doesn’t report is empty. These are additions, so existing responses keep every field they had.

Screenly 26.10.2: A new editor for screen notes, with room for much longer notes

Thu, 08 Oct 2026 00:00:00 +0000

Screen notes are easy to overlook, but they’re a good place to keep what you know about a screen: which cabinet its player sits in, who has the key, which port on the switch it’s plugged into. We’d like more teams to use them, so this release gives them room to be useful. Until now they were a small text box on the screen’s Settings tab, capped at 255 characters and shown as plain text.

Notes now have a tab of their own, under Screens > a screen > Notes, and an editor with a formatting toolbar. They show as formatted text, with headings, bullet and numbered lists, quotes, and links you can click, and Markdown you paste in keeps its formatting. Notes can run to 65,536 characters.

For developers

On API v4.1, notes are the screen’s description field, which now takes up to 65,536 characters, up from 255.

Screenly 26.10.0: API v3's screens, playlists, groups, and assets endpoints are switched off

Thu, 01 Oct 2026 00:00:00 +0000

API v3 has reached the date we announced in July. From October 1, 2026, the v3 endpoints for managing screens, playlists, groups, and assets no longer work:

Requests to /api/v3/assets/, /api/v3/groups/, /api/v3/playlists/, and /api/v3/screens/ get a 410 Gone response, with an error that points to the API reference.
The URLs for a single item under those paths, such as /api/v3/screens/<id>/, no longer work either.

2 calls keep working for now, so older versions of the Screenly CLI can still add and remove screens: POST /api/v3/screens/ adds a screen, and DELETE /api/v3/screens/<id>/ removes one.

The same data is in API v4.1, at /v4.1/assets, /v4.1/labels (what v3 called groups), /v4.1/playlists, and /v4.1/screens. The API reference covers each one.

If an integration still calls these v3 endpoints: its requests fail from October 1, 2026. Move them to the API v4.1 endpoints above.

Screenly 26.9.8: Playlists on API v4 and v4.1 include when they were created

Thu, 24 Sep 2026 00:00:00 +0000

Playlists returned by /v4/playlists and /v4.1/playlists now carry a created_at field with the time the playlist was created, such as 2023-05-30T11:19:22+00:00. You can filter on it like any other field, so created_at=gte.2026-09-01 lists the playlists made since September 1, 2026.

It’s the same date the Playlists page shows in its new Created column.

Screenly 26.8.3: The label type field on the API now has three values instead of nine

Mon, 17 Aug 2026 00:00:00 +0000

Labels on API v4 and v4.1 carry a type, and that field described how a label was maintained. With Screenly no longer maintaining any label automatically, 6 of its 9 values no longer exist: landscape, portrait, full_hd, uhd, anywhere and virtual. What remains is all-screens, manual and screen.

Labels that reported one of the removed types now report manual, since that is what they have become, and keep their id. The exception is a workspace that already had a label of its own with the same name, such as its own Landscape: the two were merged into that existing label, and the former automatic label’s id no longer exists.

If this affects you: an integration that filters labels by type=landscape, or any of the other five, now gets an error back, because the value is no longer valid for the field. Filter by label name instead, or read the screen’s own resolution and orientation where you were using the label as a proxy for hardware. If you stored the id of an automatic label, look the label up by name again.

Screenly 26.8.2: last_ping is no longer null for a screen that has never connected

Fri, 14 Aug 2026 00:00:00 +0000

A screen’s last_ping used to be null until the screen first checked in, which made null a usable signal for “this screen has never connected”. It is now always a timestamp: screens start with theirs set to when the screen was created, and existing screens that never checked in were given their creation time.

This affects last_ping on the v4 screens resource. The field’s type and the response shape are unchanged, only the values.

If this affects you: an integration treating a null last_ping as “never connected” loses that signal. A screen created in the last four hours can also report Online in its status before the device has ever reached us, because the seeded timestamp is recent. The closest check is comparing last_ping with the screen’s created_at: a screen that has never checked in still carries the timestamp it was created with.

Screenly 26.7.1: Screens with nothing scheduled no longer report Inactive

Mon, 27 Jul 2026 00:00:00 +0000

The screen status value changed on both v4 and v4.1. A screen that is reachable and in sync but has nothing scheduled used to report Inactive. It now reports Online. Nothing else about the field changed: Out of sync, Offline and the rest behave as they did, and a disabled screen still reports Inactive.

If this affects you: an integration that reads status == "Inactive" to find screens with nothing to play will now find none of them. Check for an empty playlist directly rather than reading it off the status.