API Reference

Use any of the following commands to control asset playback: * `next` - Show the next asset * `previous` - Show the previous asset * `asset&{asset_id}` - Show the asset with the specified `asset_id`

The content of the asset. `type` can either be `file` or `url`. In case of a file, the fields `mimetype`, `filename`, and `content` will be present. In case of a URL, the field `url` will be present.

On-demand reachability recheck, called from the viewer. The viewer cannot attach operator BasicAuth credentials, so this endpoint uses a lightweight internal token derived from the shared ``anthias.conf`` secret instead. The request still remains side-effect-only and rate-limited: it returns no asset data, queue churn is debounced here, and the Celery task enforces the longer per-asset probe cooldown.

Create a backup of the current Anthias instance, which includes the following: * current settings * image and video assets * asset metadata (e.g. name, duration, play order, status), which is stored in a SQLite database

Import a single remote media item as an Anthias asset. Per-item (not batch) for the same reason as ``ScreenlyMigrateAssetViewV2``: the wizard shows live progress and keeps going past individual failures. Known per-item failures return 200 with ``success: False`` so the queue keeps advancing; only a transport failure is a 502.

Validate an import provider's token and enumerate its media. Inbound counterpart to ``ScreenlyValidateTokenViewV2``: validation and listing happen in one round-trip so the wizard's Continue button goes straight from the token field to the item picker. The token is not stored; each request forwards it inline. ``provider`` is the registry key from the URL (``yodeck``, later ``screencloud`` …).

Forward a single Anthias asset to the configured Screenly account. Per-asset rather than batch on purpose: the UI shows live progress and continues past individual failures, which matches the way operators run this (large libraries, some assets reachable, some not). Batching would either swallow partial failures or hand-roll the same loop server-side with worse feedback.

Probe a Screenly v4.1 API token and reserve the migration group. Two steps in one round-trip because the wizard's UX is "click Continue → either an error or the asset picker". Validating the token alone would leave a follow-up call between Continue and the next screen, and the asset-group creation is cheap (idempotent get-or-create against ``/asset-groups``). The token is not stored; each request forwards it inline.

Lightweight IP-list endpoint for the splash page to poll. Unauth'd because the splash page itself is unauth'd and the viewer isn't a credentialed client. The data here is already disclosed by /splash-page rendering — there's no new exposure. Narrow on purpose: only IPs, no diagnostics. /api/v2/info covers the "everything about the device" case but is auth'd and does heavier work (psutil, statvfs, version checks) that would compound on a 2-second poll. Don't bolt onto this; add a sibling endpoint if a different unauth'd value is ever needed. **KNOWN LIMITATION (deferred to broader auth work).** This GET has a side effect — ``_resolve_node_ip`` calls ``_publish_refresh()`` on cache miss / hit / empty-list, which publishes ``hostcmd: set_ip_addresses`` to host_agent. ``host_agent.set_ip_addresses`` in turn does an internet probe (``requests.get`` to 1.1.1.1 with a 10×1s tenacity retry). An unauthenticated LAN client can drive that side effect at the debounce-bounded rate (one publish per ``_IP_REFRESH_DEBOUNCE_S``). The mitigations already in place keep blast radius bounded: * SETNX-debounced publishes (only one refresh per 12s window regardless of poll volume), * the response body carries no data not already disclosed by the splash page itself, * host_agent's own retry/throttle behavior caps the downstream cost. The proper fix is a shared internal-auth gate (matching the one on AssetRecheckViewV2) — but the splash polling endpoint is consumed by the viewer's webview from the device's local network with no way to attach BasicAuth, so internal-auth here needs to be designed alongside the broader auth rework. Tracked in the same followup as AssetRecheckViewV2's gating.

Is the wifi-connect setup portal up, and what joins it? Polled by the viewer so it can put the setup instructions on the screen for as long as the portal is live, and read by /hotspot to render them. Unauth'd for the same reason as the sibling IP endpoint: the consumer is the device's own webview, which has no credentials to present. The passphrase in this response is the one thing here that isn't already public. It is exposed only while ``active`` is true, i.e. while the access point it unlocks is being broadcast and shown full-screen on the device anyway, and it is regenerated on every run of the portal. A device that is online returns ``active: false`` and no credentials at all.

Recover data from a backup file. The backup file must be a `.tar.gz` file.

Active assets + next deadline, evaluated against server time. Intended for the C++ viewer (GH #2906 Phase 3) so the viewer no longer needs Django ORM access or its own ``Asset.is_active()`` re-implementation. The Python viewer keeps using ``anthias_viewer.scheduling.generate_asset_list()`` directly until Phase 3 swaps it. Internal-auth gated for the same reason as ``AssetRecheckViewV2``: the viewer can't attach operator BasicAuth, so it presents the shared token derived from ``anthias.conf``.

Viewer-relevant settings subset for the C++ viewer. Narrower than ``DeviceSettingsViewV2`` on purpose: only the keys the viewer reads at runtime are exposed, so the internal-auth path doesn't surface operator credential fields. Internal-auth gated like ``ViewerPlaylistViewV2`` above.