{
    "date":  "2026-08-19T07:29:17.7425657Z",
    "workItems":  [
                      {
                          "title":  "Platform API extended configuration options",
                          "description":  "\u003cdiv\u003eallowedOrigins (for CORS) and \u003cspan\u003ecloudAuthority have been added to Api plugin settings.\u003c/span\u003e \u003c/div\u003e",
                          "id":  1149,
                          "type":  "User Story",
                          "state":  "Resolved"
                      },
                      {
                          "title":  "Nixxis cloud single sign-on for agents and applications",
                          "description":  "\u003cdiv\u003eNCS\ncan now validate tokens issued by the Nixxis cloud identity service, in\naddition to its own local authentication. Both mechanisms operate side by side:\na token that is not recognised as a cloud token falls back to the existing\ninternal authentication, so current clients keep working unchanged. \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u003c/div\u003e\u003cdiv\u003eFeatures: \u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e \u003c/div\u003e\u003cdiv\u003e \u003c/div\u003e\u003cdiv\u003e-\nCloud sign-on — agents authenticate through the cloud identity service and are\nmapped onto their existing NCS account. Signing keys are discovered and rotated\nautomatically, with no manual key distribution. \u003c/div\u003e\u003cdiv\u003e-\nRole and strength-based authorization — API endpoints can now require cloud\nroles, cloud-only authentication, or a minimum authentication strength\n(multi-factor). Authenticated users lacking permission receive a clear\n\u0026quot;forbidden\u0026quot; response instead of a repeated login prompt. \u003c/div\u003e\u003cdiv\u003e-\nUnified account information — new endpoints expose the current user\u0027s profile,\nroles and claims consistently, whether they signed in locally or through the\ncloud. \u003c/div\u003e\u003cdiv\u003e- API\nkeys and trusted hosts — applications and local integrations (IVR, media\nservers, context data) can be granted access through configured API keys, or by\nbeing recognised from their network address, without embedding agent\ncredentials. \u003c/div\u003e\u003cdiv\u003e-\nEnforced access control — application-server HTTP endpoints now actively\nrequire authentication instead of only logging unauthenticated access.\nDiagnostic pages, previously disabled outright, are available again to\nauthenticated users. \u003c/div\u003e\u003cdiv\u003e-\nConfigurable cross-origin access — allowed web origins are now set per\ninstallation instead of being unrestricted. \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u003c/div\u003e\u003cdiv\u003eNew\nsettings: cloudAuthority and ApiAllowedOrigins (API application, available in\nthe administrator), security.CloudAuthority and an \u0026lt;apikeys\u0026gt; section\n(server configuration file). \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u003c/div\u003e\u003cdiv\u003eAPI\nkeys are declared in Http.config, in an \u0026lt;apikeys\u0026gt; section placed directly\nunder a \u0026lt;domain\u0026gt; element, alongside the existing \u0026lt;credentials\u0026gt;\nsection. The list applies to every application of that domain. \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u003c/div\u003e\u003cdiv\u003e\u0026lt;apiKeys\u0026gt; \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u0026lt;add key=\u0026quot;MyKeyHere\u0026quot; role=\u0026quot;100\u0026quot; /\u0026gt; \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u0026lt;add key=\u0026quot;\u003ca href=\"mailto:IN@1.2.3.4\"\u003eIN@1.2.3.4\u003c/a\u003e\u0026quot;\nrole=\u0026quot;100\u0026quot; /\u0026gt; \u003c/div\u003e\u003cdiv\u003e\u0026lt;/apiKeys\u0026gt; \u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e \u003c/div\u003e\u003cdiv\u003e \u003c/div\u003e\u003cdiv\u003eEach\n\u0026lt;add\u0026gt; entry maps a key to a role, which identifies the NCS user the\nrequest is attributed to. Two kinds of entries are supported: \u003c/div\u003e\u003cdiv\u003e\u0026nbsp; \u003c/div\u003e\u003cdiv\u003e- A\nshared secret — matched against the x-api-key request header. For callers that\ncannot set arbitrary headers, the same value is also accepted as a bearer token\nin the Authorization header. \u003c/div\u003e\u003cdiv\u003e- A\nnetwork address, written IN@\u0026lt;ip-address\u0026gt; — matched against the caller\u0027s\naddress when no key is presented. This lets trusted hosts such as media servers\nor IVRs be identified without distributing a secret to them. \u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e \u003c/div\u003e\u003cdiv\u003e\u003cbr\u003e \u003c/div\u003e",
                          "id":  1225,
                          "type":  "User Story",
                          "state":  "Resolved"
                      }
                  ],
    "id":  1356,
    "version":  "3.3.1356"
}