Automating your show with the Timers Studio REST API

I automated my first show in 2019 using a Python script that sent OSC messages to a proprietary timer application running on a Windows laptop tucked under a mixing desk. The script worked exactly once, during rehearsal, and then failed spectacularly during the live show because the laptop had gone to sleep and the OSC socket had closed. That experience taught me a lesson I carry to every production: automation is only as reliable as the connection between systems. The Timers Studio REST API is HTTP-based, which immediately solves the most common automation failure modes. HTTP does not care about persistent sockets. If your automation server restarts, the next request still works. If the network blips, the request either succeeds or returns an error code that your script can handle. There is no session to reconnect, no handshake to renegotiate, no state to restore. Here are the practical basics. Authentication uses Bearer tokens. You generate an API key in your Timers Studio dashboard, and every request includes it in the Authorization header. The token is scoped to your account, so it can access any studio you own. There is no OAuth dance, no refresh tokens, no expiry to manage. For show automation, simplicity in authentication is a feature, not a shortcoming. You do not want your cue-triggering script to fail because a token expired mid-show. The most common automation pattern is timer control. The API exposes endpoints for every timer action: start, pause, resume, stop, reset, and next-cue. A typical automation might look like this. Your video playout system finishes a VT. It sends a webhook to your automation server. Your server calls the Timers Studio API to advance to the next cue. The new countdown appears on every screen in the room within 200 milliseconds. No human pressed a button. No one had to watch the VT and react at the right moment. Here is a concrete example. Suppose your show has a segment called "Product Demo" that should last exactly eight minutes. You want the timer to start automatically when the demo application signals that it is ready. Your demo app sends an HTTP POST to your automation endpoint. Your middleware receives the signal and calls POST /api/v1/cues/next with your Bearer token. Timers Studio advances to the Product Demo cue and starts the eight-minute countdown. Every player, moderator console, and audience display updates simultaneously. The real-time dimension comes from Server-Sent Events. While the REST endpoints let you send commands to Timers Studio, SSE lets Timers Studio push state changes back to you. You open a single HTTP connection to the SSE endpoint, and Timers Studio streams every state change as it happens: timer started, timer paused, cue advanced, message sent, question submitted. Your automation can react to these events in real time without polling. This is powerful for cross-system synchronization. Imagine you want your lighting console to change scenes when a timer enters its warning zone. Your automation server subscribes to the SSE stream. When it receives a "timer_warning" event, it sends an HTTP command to your lighting API. The lights change color at exactly the moment the timer turns yellow on screen. The coordination is automatic, instantaneous, and consistent every single time. One pattern I use frequently is what I call the "show state machine." Instead of scripting individual API calls for each transition, I define a state machine where each state represents a show segment and each transition represents an event. When the SSE stream emits "cue_advanced," the state machine moves to the next state and triggers whatever cross-system actions are defined for that transition. This approach scales beautifully because adding a new cue to the rundown only requires adding a new state to the machine. The automation logic never needs to know the specific content of each segment. For teams that prefer no-code automation, the Timers Studio API works seamlessly with n8n, Make, and Zapier. You can create a workflow that starts your keynote countdown when a Google Calendar event begins, or one that sends a Slack notification to your production channel when a timer runs into overtime. The API follows standard REST conventions with JSON request and response bodies, which means any HTTP-capable tool can interact with it. Error handling is straightforward. Every endpoint returns standard HTTP status codes. A 200 means success. A 401 means your token is invalid. A 404 means the timer or cue you referenced does not exist. A 429 means you are sending requests too fast, which in practice only happens if you have a runaway loop in your automation script. The response body always includes a descriptive error message in addition to the status code. Rate limits are generous for production use. The API allows 120 requests per minute per token, which is far more than any reasonable show automation would generate. Even a show with rapid-fire 30-second segments would only generate two or three API calls per minute. If you somehow hit the limit, the 429 response includes a Retry-After header telling your script exactly how long to wait. Here is another real-world pattern. At a recent three-day conference, we used the API to build a "show dashboard" that aggregated timer states from twelve simultaneous breakout sessions into a single producer view. Each breakout room ran its own Timers Studio instance. A small Node.js service subscribed to the SSE stream from each instance and pushed the aggregated state to a custom web dashboard. The executive producer could see, at a glance, which rooms were on time, which were running behind, and which had audience questions pending. That dashboard took four hours to build because the API is so predictable that there were no surprises during development. The complete API reference documents all 53 endpoints with request parameters, response schemas, and curl examples. If you can write a curl command, you can automate your show. That was the design goal, and based on the production setups I have built over the past year, it delivers on that promise.