weather scene must not take Radio 2’s weather scene after the studio switched station.
The Core API has two tools for this: pinning a device to a station and the ?station= parameter. Together they are the station guard.
Which routes are station-scoped
Every other route, macros, signals and cameras included, acts on the studio and works whatever station is on it. Macros are the macros the Core has loaded for the station on the studio, but a pin does not hold them back. Every successful answer of a station-scoped route carries the station it acted on:
Pin a device to a station
Set Station on the device in Studio settings → Core API → Devices. While another station holds the studio, the device’s station-scoped calls answer409 station_mismatch. Its studio calls, like /api/v2/studio/onair, keep working.
This is the simplest option: the panel needs no extra parameter and cannot act on the wrong station. The pin is always enforced; a ?station= on the call is checked in addition to it, so a pinned device cannot talk itself onto another station.
Name the station on the call
Add?station= with the station id or name to any route. Names are matched case-insensitively, ids exactly. When another station holds the studio, the call answers 409 station_mismatch and does nothing.
?station= works on studio routes too. /api/v2/studio/onair?station=Radio%201 only puts the studio on air while Radio 1 is on it.
A refused call names the expected and the actual station:
ERR station_mismatch.
Calls that name no station
There are no guard modes. The studio owns the station that is on it, so a station-scoped call from a device without a pin and without?station= acts on that station. The guard only stops a key that is fixed on another station: a pin or ?station= that does not match the station on the studio answers 409 station_mismatch.
Fix the key whenever the studio rotates between stations. A Stream Deck page built for Radio 1 must not fire on the studio after it rotates to Radio 2: pin the device to Radio 1, or add ?station=Radio%201 to its calls.
While the studio switches station
The Core follows the station on its studio live. When the studio switches station in VRA Cloud, the Core hears of it at once and asks the cloud which station is on the studio now. Until that answer is in, a call that names a station, by pin or by?station=, answers 409 station_changing. Handle it like 503: retry after a moment. A call that names no station is not held up; it acts on the station the Core knew last.
The station in the answers, in GET /api/v2/station and in the guard follows the swap straight away.
Variables
Variables are written through VRA Cloud. Besides the checks above, the Core sends the station it is on with every write, and the cloud refuses the write with409 station_mismatch when another station holds the studio by then. A write can therefore not land on the wrong station, even in the moment before the Core has seen a swap.
For outputs, ?station= is also held against the station of the output itself. An output that still plays another station’s show answers 409 station_mismatch with expected and output_station_id.