> ## Documentation Index
> Fetch the complete documentation index at: https://docs.visualradioassist.live/llms.txt
> Use this file to discover all available pages before exploring further.

# Studio control

> Put studios on air and activate or deactivate their Core through the Cloud GraphQL API, by studio id or studio name.

Three mutations control a studio the way the studio panel in VRA Cloud does. They send the same internal commando to the Core, so the Core applies the change, updates its state and every connected client follows. Use them from a scheduling system, a control surface or a script that switches studios without an operator in the app.

## How it works

1. You call a mutation with the station and one or more studios.
2. VRA Cloud resolves each studio by id or by its internal name within the station.
3. VRA Cloud sends an internal commando to the Core of each studio over the studio bus.
4. The Core applies the state and publishes its new state to VRA Cloud and all clients.

<Note>
  The Core needs to be online. A commando to a studio without a running Core is not queued. The Core also keeps its own rules, so while the Core is in a state like standby it rejects the commando like it would from the app.
</Note>

## Authentication

Authenticate as a [Machine User](/develop-with-vra/cloud-graphql-api/machine-users) of the station, or as a cloud user who has the station active.

## Addressing a studio

`studio_id` accepts the studio id or the studio name, the internal name of the studio in VRA Cloud. Names are matched exactly and only within the given station, so a script can use `Studio_1` instead of a UUID.

## Put a studio on air

```graphql theme={null}
mutation {
  setStudioOnAirState(input: {
    station_id: "94bf2c80-2fb6-4c0a-b33d-5d2d1bb888e7"
    studio_id: "Studio_1"
    state: ON_AIR
  }) {
    ok
    studio_ids
  }
}
```

`state` is `ON_AIR`, `OFF_AIR` or `TOGGLE`. `TOGGLE` flips whatever the Core currently has.

## Switch several studios at once

The station level mutation takes a list of studios with their new state. Every studio is resolved before anything is sent, so one unknown name fails the whole call and no studio changes.

```graphql theme={null}
mutation {
  setStationStudiosOnAirState(input: {
    station_id: "94bf2c80-2fb6-4c0a-b33d-5d2d1bb888e7"
    studios: [
      { studio_id: "Studio_1", state: OFF_AIR }
      { studio_id: "Studio_2", state: ON_AIR }
    ]
  }) {
    ok
    studio_ids
  }
}
```

## Activate or deactivate a Core

```graphql theme={null}
mutation {
  setCoreActivationState(input: {
    station_id: "94bf2c80-2fb6-4c0a-b33d-5d2d1bb888e7"
    studio_id: "Studio_1"
    state: ACTIVE
  }) {
    ok
    studio_ids
  }
}
```

`state` is `ACTIVE`, `DEACTIVATED` or `TOGGLE`. A deactivated Core stops handling switcher and camera commandos until it is activated again.

## Response

Every mutation returns the same shape.

```json theme={null}
{
  "data": {
    "setStudioOnAirState": {
      "ok": true,
      "studio_ids": ["99abda79-9c21-42a2-bb17-08f7886de136"]
    }
  }
}
```

* **ok** - the commando was sent.
* **studio\_ids** - ids of the studios it was sent to, useful when you addressed them by name.

An unknown studio returns `No studio 'name' in this station`, a station you have no access to returns `Not authorized for this station`.

## Related

* [AutomationLink ingest](/develop-with-vra/cloud-graphql-api/automationlink-ingest) to push now playing data through the same API.
* [Core Control API](/develop-with-vra/core-control-api) for control on the studio network, including [Bitfocus Companion](/develop-with-vra/core-control-api/bitfocus-companion-control-over-visual-radio).
