NDI configuration

NDI configuration is where you define how this Callaba instance should behave as an NDI participant on the network. In production, this is the page that matters when discovery must work across the right subnets, the machine should present the right identity, or the engine needs to follow a site-wide NDI discovery plan.

The important user question here is not how the form and JSON stay in sync. It is whether the engine will appear on the network in the right way, discover the right peers, and stop surprising operators with missing devices or inconsistent naming.

Read this page as NDI behavior for the whole instance. If discovered devices tell you what the engine sees, this page is where you decide how the engine should participate in that NDI environment in the first place.

Examples by preset

The practical presets here are a simple machine-and-network update and a fuller JSON-driven site configuration.

Minimal machine and network update

{
  "machinename": "CALLABA CLOUD STUDIO",
  "ips": "192.168.10.41, 192.168.10.52",
  "discovery": "192.168.10.20:5959",
  "json": {
    "ndi": {
      "machinename": "CALLABA CLOUD STUDIO",
      "networks": {
        "discovery": "192.168.10.20:5959",
        "ips": "192.168.10.41, 192.168.10.52"
      }
    }
  }
}

Multi-discovery site configuration

{
  "machinename": "CALLABA CLOUD STUDIO",
  "ips": "192.168.10.41, 192.168.10.52",
  "discovery": "192.168.10.20:5959, 192.168.10.21:5959",
  "json": {
    "ndi": {
      "machinename": "CALLABA CLOUD STUDIO",
      "networks": {
        "discovery": "192.168.10.20:5959, 192.168.10.21:5959",
        "ips": "192.168.10.41, 192.168.10.52"
      }
    }
  }
}

Workflow examples

Use NDI configuration when the engine must discover devices on the right networks

This is the place to adjust discovery servers, machine identity, and network reachability when the default behavior is not enough for the site.

  • Why it helps: the engine becomes easier to place inside a real facility instead of only working in a default lab-style network.
  • Typical fit: multi-subnet deployments, dedicated discovery servers, venue-wide naming standards, and controlled NDI environments.

Stabilize the instance identity for operators and connected systems

When multiple teams or rooms interact with the same engine, consistent machine naming matters. This page helps make the Callaba instance show up under a predictable identity.

  • Why it helps: operators spend less time guessing which NDI endpoint belongs to which environment.
  • Operational fit: studios with multiple engines, shared event networks, and deployments where naming clarity matters as much as transport reliability.

Reset to a known-good baseline after a bad experiment

Configuration problems are often easier to solve when the team can return to a trusted baseline and rebuild carefully from there.

  • Why it helps: recovery is faster when the system can be brought back to a sane discovery state before more changes are layered on top.
  • Operational fit: bad imports, risky manual edits, and troubleshooting after discovery stopped working the way the room expects.
Update NDI configuration
Collapse
POST
/api/devices/updateNDIConfiguration

Use Update NDI configuration to apply app-level NDI settings such as machine naming, discovery servers, explicit network IPs, or a full imported JSON configuration.

This endpoint matters because one save can change how the whole instance behaves in the NDI environment, rather than only changing one item in a list.

Use it when the goal is straightforward and production-facing: make NDI discovery behave the right way for this instance and keep that behavior consistent after the save.

App-level configuration

Use this when the visible form fields are enough and you want the JSON editor to stay in sync with those values.

Minimal form-driven update

This mirrors the normal UI path where form changes and JSON changes stay aligned before save.

Minimal form-driven update
curl --request POST \
--url http://localhost/api/devices/updateNDIConfiguration \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"machinename": "CALLABA CLOUD STUDIO",
"ips": "192.168.10.41, 192.168.10.52",
"discovery": "192.168.10.20:5959",
"json": {
"ndi": {
"machinename": "CALLABA CLOUD STUDIO",
"networks": {
"discovery": "192.168.10.20:5959",
"ips": "192.168.10.41, 192.168.10.52"
}
}
}
}'
Full JSON-driven update

This matches the live-editor and import flow in the UI.

Full JSON-driven update
curl --request POST \
--url http://localhost/api/devices/updateNDIConfiguration \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"machinename": "CALLABA CLOUD STUDIO",
"ips": "192.168.10.41, 192.168.10.52",
"discovery": "192.168.10.20:5959, 192.168.10.21:5959",
"json": {
"ndi": {
"machinename": "CALLABA CLOUD STUDIO",
"networks": {
"discovery": "192.168.10.20:5959, 192.168.10.21:5959",
"ips": "192.168.10.41, 192.168.10.52"
}
}
}
}'
Request body parameters
Form fields
machinename
string

Dashboard label: Machine name.

Optional override for the machine name announced through the NDI network behavior.

discovery
string

Dashboard label: Discovery.

Comma-separated discovery-server list. The UI tooltip explicitly allows port numbers as part of the values.

ips
string

Dashboard label: Networks ips.

Comma-separated list of explicit source IPs for cross-subnet discovery scenarios.

JSON editor
json
object

The live JSON editor model. The UI keeps this object synchronized with the visible form fields and imported config files.

Update NDI configuration
curl --request POST \
--url http://localhost/api/devices/updateNDIConfiguration \
--header 'x-access-token: <your_api_token>' \
--header 'Content-Type: application/json' \
--data '{
"machinename": "CALLABA CLOUD STUDIO",
"ips": "192.168.10.41, 192.168.10.52",
"discovery": "192.168.10.20:5959",
"json": {
"ndi": {
"machinename": "CALLABA CLOUD STUDIO",
"networks": {
"discovery": "192.168.10.20:5959",
"ips": "192.168.10.41, 192.168.10.52"
}
}
}
}'
Response
Operation result
success
boolean

The backend returns { success: true } after validating, writing, and applying the updated NDI configuration.

Apply behavior
side effects
config write + apply path

The backend writes the compiled config, stores ndi_settings on the app object, and triggers the ingress/apply path used by the engine to pick up the new NDI behavior.

Response: Update NDI configuration
JSON
{
"success": true
}