General settings

General settings

Use General settings to manage engine-wide behavior. These endpoints control how the instance is exposed over HTTP and HTTPS, which domains and certificates it serves, and how configuration is moved between environments.

Changes here affect the whole instance, not a single room or transport. Apply them deliberately, verify the result immediately, and use export/import when you need a repeatable baseline for staging, backup, or replacement environments.

Common configuration payloads

These examples cover the main instance-level tasks: updating network-facing delivery settings, installing a certificate, and writing custom defaults.

{
  "http_modes": [
    { "mode": "HTTPS" },
    { "mode": "HTTP" }
  ],
  "cdn_domain_name": "cdn.example.com",
  "streaming_domain_name": "stream.example.com"
}
{
  "ssl_type": "SSL_TYPE_CUSTOM",
  "ssl_domain_name": "stream.example.com",
  "certificate": "-----BEGIN CERTIFICATE-----...",
  "private_key": "-----BEGIN PRIVATE KEY-----..."
}
{
  "custom_settings": {
    "showBrandName": false,
    "useCustomLogo": true
  }
}

Production workflows

Bring a new instance online with the correct domains

Start with getAppInfo to inspect current state. Then use updateHTTPConfig to set the intended domains and delivery modes. If the instance will serve HTTPS, install the certificate before exposing the instance to live users or operators.

Apply certificate updates safely

Use updateSSLCertificate when a certificate is renewed or a domain changes. Confirm that the certificate matches the active hostname and schedule the change carefully if the instance is already serving production traffic.

Keep instance defaults consistent across environments

Use updateCustomSettings for instance-wide defaults, branding, or policy changes that should apply everywhere. Use exportDb and importDb when you need to replicate a known-good configuration into staging, recovery, or replacement environments.

Get app info
Collapse
POST
/api/application/getAppInfo

Use this as the first call in any management client before making instance-wide changes.

It gives you the current instance configuration and status snapshot so the team can confirm they are operating the right environment before touching domains, certificates, timing, or imported settings.

Request body parameters
This method has no parameters
Get app info
curl --request POST \
  --url http://localhost/api/application/getAppInfo \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{}'
Response
Identity
name / login / token
mixed

Instance identity fields returned for the current application.

Versioning
app_version / stack_version / node_app
mixed

Current engine version and deployment flavor.

Delivery
http_modes / cdn_domain_name / streaming_domain_name
mixed

Current HTTP and domain configuration returned by the engine.

Custom settings
custom_settings
object

Persisted custom application settings.

Operation result
success
boolean

Successful responses expose success: true.

Response: Get app info
JSON
{
  "app_version": "8.2.p.NDI.pre-aws",
  "stack_version": "8.2",
  "node_app": "NODE_APP_SELF_HOSTED",
  "name": "All-in-one. SaaS",
  "login": "admin",
  "token": "<jwt_token>",
  "custom_settings": {
    "showBrandName": false,
    "useCustomLogo": true
  },
  "http_modes": [
    {
      "mode": "HTTPS"
    },
    {
      "mode": "HTTP"
    }
  ],
  "cdn_domain_name": "cdn.example.com",
  "streaming_domain_name": "stream.example.com",
  "success": true
}
Update HTTP config
Expand
POST
/api/application/updateHTTPConfig

Use this before go-live or during a planned cutover to set the public HTTP and HTTPS delivery settings for the instance.

Because it affects how viewers, encoders, and integrations reach the engine, coordinate this change with DNS, proxy, and certificate updates.

Request body parameters
http_modes[]
array

List of enabled delivery modes. Real product values include HTTP and HTTPS.

cdn_domain_name
string

Domain used for CDN-style delivery references.

streaming_domain_name
string

Domain used for stream-facing URLs.

Update HTTP config
curl --request POST \
  --url http://localhost/api/application/updateHTTPConfig \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "http_modes": [
    {
      "mode": "HTTPS"
    },
    {
      "mode": "HTTP"
    }
  ],
  "cdn_domain_name": "cdn.example.com",
  "streaming_domain_name": "stream.example.com"
}'
Response
success
boolean

The backend confirms that the HTTP configuration update was accepted.

Response: Update HTTP config
JSON
{
  "success": true
}
Update SSL certificate
Expand
POST
/api/application/updateSSLCertificate

Use this before exposing a new domain or when rotating expiring certificates on a live instance.

It is the production path for moving to a custom certificate or renewing the active SSL policy; coordinate it with domain and HTTP changes so viewers and integrations do not hit trust or reachability issues.

Request body parameters
ssl_type
string

SSL policy to apply. Real product values include custom, self-signed, and Let's Encrypt flows.

ssl_domain_name
string

Domain name that the certificate configuration should protect.

certificate
string

PEM certificate body when the selected SSL mode requires a custom certificate.

private_key
string

Matching PEM private key when the selected SSL mode requires one.

Update SSL certificate
curl --request POST \
  --url http://localhost/api/application/updateSSLCertificate \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "ssl_type": "SSL_TYPE_CUSTOM",
  "ssl_domain_name": "stream.example.com",
  "certificate": "-----BEGIN CERTIFICATE-----...",
  "private_key": "-----BEGIN PRIVATE KEY-----..."
}'
Response
result / success
mixed

The backend confirms whether the SSL update completed successfully.

Response: Update SSL certificate
JSON
{
  "success": true,
  "result": true
}
Update custom settings
Expand
POST
/api/application/updateCustomSettings

Use this to roll out instance-wide branding, defaults, or behavior changes that should stay consistent across operator and viewer workflows.

Treat it as a shared configuration change: apply it deliberately, especially on a live system where UI behavior or presentation may change immediately.

Request body parameters
custom_settings
object

Object of persisted instance-level feature flags and UI behavior settings.

Update custom settings
curl --request POST \
  --url http://localhost/api/application/updateCustomSettings \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "custom_settings": {
    "showBrandName": false,
    "useCustomLogo": true
  }
}'
Response
success
boolean

The backend confirms that the custom settings write finished successfully.

Response: Update custom settings
JSON
{
  "success": true
}
Import DB
Expand
POST
/api/application/importDb

Use this to apply a known-good settings baseline to a new, recovered, or replacement Callaba Engine instance.

Because it can change configuration across modules, run it in a maintenance window and verify domain, HTTP, and SSL implications before reopening production traffic.

Request body parameters
file_path
string

Path to the previously exported dump that should be imported.

Import DB
curl --request POST \
  --url http://localhost/api/application/importDb \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "file_path": "uploads/callaba-dump.gz"
}'
Response
success / app_version
mixed

Import confirmation together with the target application version returned by the engine.

Response: Import DB
JSON
{
  "success": true,
  "app_version": "8.2"
}
Export DB
Expand
POST
/api/application/exportDb

Use this before migrations, upgrades, or other instance-wide changes when you need a portable settings snapshot for rollback or handoff.

It exports the selected module settings into a reusable dump that can be archived, transferred, or re-imported later.

Request body parameters
modules[]
array

List of module identifiers that should be included in the exported dump.

Export DB
curl --request POST \
  --url http://localhost/api/application/exportDb \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "modules": [
    "MODULE_SRT_SERVERS",
    "MODULE_SRT_ROUTERS",
    "MODULE_RTMP_SERVERS",
    "MODULE_RESTREAM",
    "MODULE_VOD"
  ]
}'
Response
result / success
mixed

Path to the exported dump plus a success-shaped confirmation.

Response: Export DB
JSON
{
  "success": true,
  "result": "uploads/callaba-dump.gz"
}
Update NTP configuration
Expand
POST
/api/application/updateNTPConfiguration

Use this when compliance rules or timing accuracy require the instance to follow a specific time source.

Change it carefully on production systems, because stable clock behavior affects recordings, schedules, and event timing across the instance.

Request body parameters
ntp_server
string

NTP hostname that the instance should use as its time source.

Update NTP configuration
curl --request POST \
  --url http://localhost/api/application/updateNTPConfiguration \
  --header 'x-access-token: <your_api_token>' \
  --header 'Content-Type: application/json' \
  --data '{
  "ntp_server": "time.apple.com"
}'
Response
success
boolean

The backend confirms that the NTP configuration update was accepted.

Response: Update NTP configuration
JSON
{
  "success": true
}
Next toPorts