Create NMS configuration entry

Creates a key in the NMS configuration table (config_config) and replicates it to every core server.

Requires Super User.

config-name takes letters, digits, ., _, and -, the characters GET /nmsconfig/{config-name} can address. An existing key returns 409, because the underlying save would otherwise overwrite it; send overwrite=yes to allow that, or use PUT. The check reads the server that takes the request, so it is a safeguard, not a lock.

config-name and config-value are both required. A mask-shaped config-value (**** or Ex****01) on a credential-shaped key returns 400 for a new key, since there is no stored value to keep; over an existing key with overwrite=yes it is dropped, and the answer is 202 with nothing changed.

The write is published over the service bus (SBUS), so 202 means accepted, not yet applied. synchronous=yes waits until every server that answers holds the new value, for up to synchronous-timeout milliseconds (default 2000, at most 5000), then answers 200 with one row per server. config-applied is yes (holds it), no (not seen there yet, which never means rejected), or unknown (the server did not answer). Replication is batched, so a short timeout often reports no.

config-server writes one server only, with no replication. Name a core server's hostname and only that server's row changes: the server that takes the request writes its own row, or forwards the write to the named server. Two things follow:

A later cluster-wide write to the same key overwrites the per-server value.

Nothing records that the difference is deliberate, so it reads as config-in-sync: no.

Leaving config-server out, or sending *, all, any, or geo, replicates to every server. A hostname that is not in the cluster returns 404. A forwarded write that gets no answer returns 502: read the key before retrying, because the server may have applied it. An inventory entry that is not a valid hostname is never contacted, and a write naming it returns 502.

Bearer Token

Provide your bearer token in the

Authorization

header when making requests to protected resources.

Example:

Authorization: Bearer ********************

Responses

🟢200OK

application/json

With synchronous=yes: one row per core server, reporting whether it holds the written value. With config-server, only that server is reported.

Bodyapplication/json

🟢202Accepted

🟠400Bad Request

🟠401Unauthorized

🟠403Forbidden

🟠404Not Found

🟠409Conflict

🔴502Bad Gateway

curl --location 'https://awqacore01.crexendocloud.com/ns-api/v2/nmsconfig?overwrite=yes&synchronous=undefined&synchronous-timeout=undefined&verify=yes&verify-timeout=3000' \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "config-name": "CdrKeepDays", "config-value": "90", "config-geo": "no" }'

[ { "config-name": "CdrKeepDays", "config-server": "core1.example.com", "config-applied": "yes" }, { "config-name": "CdrKeepDays", "config-server": "core2.example.com", "config-applied": "no" } ]