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.
The practical presets here are a simple machine-and-network update and a fuller JSON-driven site configuration.
{
"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"
}
}
}
}
{
"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"
}
}
}
}
This is the place to adjust discovery servers, machine identity, and network reachability when the default behavior is not enough for the site.
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.
Configuration problems are often easier to solve when the team can return to a trusted baseline and rebuild carefully from there.
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.
Use this when the visible form fields are enough and you want the JSON editor to stay in sync with those values.
This mirrors the normal UI path where form changes and JSON changes stay aligned before save.
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"}}}}'
This matches the live-editor and import flow in the UI.
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"}}}}'
Dashboard label: Machine name.
Optional override for the machine name announced through the NDI network behavior.
Dashboard label: Discovery.
Comma-separated discovery-server list. The UI tooltip explicitly allows port numbers as part of the values.
Dashboard label: Networks ips.
Comma-separated list of explicit source IPs for cross-subnet discovery scenarios.
The live JSON editor model. The UI keeps this object synchronized with the visible form fields and imported config files.
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"}}}}'
The backend returns { success: true } after validating, writing, and applying the updated NDI configuration.
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.
{"success": true}