The SpinetiX REST API turns every player into a programmable endpoint. External systems — monitoring dashboards, automation scripts, enterprise IT tools — interact with players through standard HTTP requests. Query player status, upload content, capture screenshots, read configuration, and trigger reboots — all via RESTful endpoints authenticated with Basic auth over HTTPS. This guide covers every integration pattern.
API Endpoint Categories
Player Status
GET /api/status returns a JSON object with player model, firmware version,
serial number, uptime, storage capacity and usage, CPU temperature, network configuration,
and current content project name. Poll this endpoint for fleet monitoring — aggregate responses
into dashboards showing health across all players.
Content Management
The player's WebDAV interface enables content operations via HTTP: PUT uploads files,
DELETE removes files, PROPFIND lists directory contents. Automated
pipelines use these endpoints to deploy content without Elementi: a script generates updated
data files, uploads them via WebDAV, and the player renders the new data immediately.
Screenshot Capture
GET /api/screenshot returns a JPEG of the player's current output — exactly what's
displayed on the connected screen. Use this for remote visual verification: is the content
displaying correctly? Is the layout rendering properly? Automated monitoring can capture
screenshots hourly and compare for unexpected changes.
Configuration
GET /api/config reads player configuration, POST /api/config updates
settings. Network parameters, display resolution, serial port settings, and scheduling
configuration are all accessible via API — enabling mass configuration of player fleets
from scripts.
Integration Patterns
| Pattern | Method | Endpoint | Use Case |
|---|---|---|---|
| Health check | GET | /api/status | Monitoring dashboard |
| Content deploy | PUT | /content/ (WebDAV) | CI/CD pipeline |
| Visual verify | GET | /api/screenshot | Remote content audit |
| Configuration | GET/POST | /api/config | Mass fleet settings |
| Reboot | POST | /api/control/reboot | Remote maintenance |
| Firmware info | GET | /api/status | Version compliance check |
Key Parameters
| Parameter | Value | Why It Matters |
|---|---|---|
| Protocol | HTTP / HTTPS | Standard web protocols, no SDK needed |
| Authentication | Basic auth | Simple credential-based access |
| Response format | JSON | Universal parsing in any language |
| Rate limiting | None (player-side) | Poll responsibly — 30s minimum interval |
| CORS | Not applicable (server-to-server) | API calls from backend, not browser |
Common Mistakes
- Polling too frequently. Hitting the status API every second from 100 monitoring agents creates unnecessary load. Poll every 30–60 seconds for status, every 5 minutes for screenshots. The player handles it, but it's wasteful.
- No HTTPS. Basic auth credentials in plain HTTP are interceptable. Always use HTTPS when API calls traverse networks beyond the local switch.
- Hardcoded player IPs. Referencing players by IP in scripts breaks when DHCP assigns a new address. Use DNS names or maintain a player registry that maps logical names to IPs via discovery.
- Ignoring error responses. When a player is rebooting or offline, API calls return errors. Scripts must handle HTTP 503, connection timeouts, and authentication failures gracefully — retry with backoff, not crash.