NDI configuration

NDI configuration controls how this Callaba instance participates in your NDI environment. Use it to set the engine name, choose the network interfaces used for NDI, and point the engine to one or more discovery servers.

In production, this page matters when the engine must appear under the correct identity, discover devices across the correct subnets, or follow a facility-wide discovery plan. If expected NDI peers are missing, duplicated, or appearing under inconsistent names, start here.

What you configure

  • Machine name: the identity shown to operators and connected systems.
  • IPs: the interfaces the engine should use for NDI traffic.
  • Discovery: one or more discovery servers for controlled or multi-subnet NDI deployments.

Examples by preset

Use the minimal preset to place one engine on the correct interfaces with a single discovery server. Use the multi-discovery preset when the site relies on more than one discovery endpoint.

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"
      }
    }
  }
}

Operational workflows

Bring an engine online on the correct subnets

Set the machine name, list the production NICs, and point the engine at the site discovery server. This is the standard setup for hosts with multiple interfaces or separate management and media networks.

  • Use when: the server has more than one NIC, devices live across subnets, or the site does not rely on default discovery.
  • Result: the engine appears where operators expect and sees the right NDI peers.

Standardize identity across rooms and events

Apply a stable machine name that matches your room, rack, or service naming standard. This reduces confusion when several engines are visible on the same network.

  • Use when: multiple rooms share infrastructure, events reuse the same hardware, or support teams need predictable endpoint names.
  • Result: faster source selection, cleaner monitoring, and fewer operator mistakes.

Recover from broken discovery settings

When testing or manual edits break visibility, restore a known-good baseline for interfaces and discovery servers before making further changes.

  • Use when: sources disappear after a network change, a discovery address was entered incorrectly, or interface selection was changed without validation.
  • Result: quicker rollback and faster return to normal NDI discovery.
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
}