Skip to main content
The .NET Core answers the routes of Core v1 on the same paths with the same bodies. Existing integrations, like a Companion page or a radio automation script, keep working after the upgrade. New integrations should use the Core API v2 routes: they have device tokens, plain-text twins, clear error codes and more features.

Routes

Base URL: http://{core_host_ip}:3002
  • /api/state/control/* judge on the Core instance state. Toggle deactivates when the state is ACTIVE and activates in every other state.
  • /api/studio/control/toggle treats recording as on air: on air or recording goes off air, off air goes on air.
  • /api/modules/outputs/control/restart restarts the Output Player apps on this machine.
  • /api/modules/control/reload pulls the Core configuration from the cloud again.
  • /api/apps/control/restart restarts the VRA apps the Core manages on this machine.
  • /status, /status/health and / need no authentication.
Text answers are text/plain; charset=utf-8, JSON answers are compact application/json; charset=utf-8. Every answer carries Cache-Control: no-store.

The state body

GET /api/state answers a compatible subset of Core v1’s state:
  • state, active, cloud and scheduling are always there.
  • cloud.studio.active is the studio state number: 0 off air, 1 on air, 2 recording.
  • The Core adds the sections it has from its own state snapshot: switcher, automation_link, signals, audio, gpio, output, automations and macro. Their content follows the .NET Core’s state, not Core v1’s.
Fields Core v1 sent that are not listed here are not part of the answer. Read what you need from the v2 routes instead.

Authorization

The legacy routes accept device tokens, LAN access and calls from the Core machine itself, like the v2 routes, and also the EXTERNAL_APP Basic header while Allow legacy authorization is on. That header opens only these routes, never /api/v2. A device limited to features needs the Legacy routes feature here. See Authentication and LAN access. The Legacy routes feature has its own Read and Control switch in Studio settings → Core API → Features.

What changed from Core v1

  • Same paths, same bodies. The routes above answer what Core v1 answered.
  • Refused actions are no longer 200. When the Core cannot apply a control route, it answers the current state (the instance state string, or onair / offair) with an error status: 503 while the Core is starting, 500 when the change failed. Core v1 answered 200 while it was not ready.
  • /api/studio/control/offair exists. The old documentation listed offair, Core v1 only answered deactivate. Both work now.
  • /api/state is a compatible subset. See The state body.
  • Restart routes act on this machine. /api/modules/outputs/control/restart and /api/apps/control/restart restart the apps the Core manages on its own machine. On Core v1, the outputs route reloaded the Output Player instances inside the Core; now it restarts the Output Player apps.
  • Device tokens and LAN access work here too. You can retire the shared EXTERNAL_APP header per device.
  • The legacy routes can be switched off per studio, with the Legacy routes feature.
The legacy routes have no plain-text twin and do not take ?wait= or ?timeout=.