Internal Configuration API

Overview

You can use the Internal Configuration API to get read and write access to low-level data from Configuration Server. See Introduction to the Configuration Layer Objects for a full list of the supported configuration objects.

Caching

Caching is not currently enabled, so any requests you make using this API go directly to Configuration Server.

Accessing the API

The following table provides basic information about accessing the Internal Configuration API:

Request URL	/api/v2/platform/configuration
HTTP Methods	GET, POST, PUT, DELETE
Required Features	api-platform-configuration-read — for read operations api-platform-configuration-write — for write operations

All configuration objects are retrieved directly from Configuration Server by using the following URI naming format: the plural version of the object name in lower case, with each word separated by a hyphen (-). Here are a few examples:

Configuration object	URI name
CfgAccessGroup	access-groups
CfgCampaign	campaigns
CfgAgentLogin	agent-logins
CfgSkill	skills

The API also supports the standard CfgQuery attributes for an object as parameters on the URI. For example, the CfgApplication object has a name attribute. Here's an example of how you could specify the name attribute:

Request

GET http://198.51.100.10:8080/api/v2/platform/configuration/applications?name=SomeName

GET Operations

You can retrieve lists of all objects in a contact center for a given object type. For example, you can get all the CfgAgentLogin objects:

Request

GET http://198.51.100.10:8080/api/v2/platform/configuration/agent-logins

Response

{
    statusCode: 0
    agent-logins: [
                {
                       useOverride: "2"
                       tenantDBID: "1"
                       DBID: "261"
                       switchSpecificType: "1"
                       userProperties: {
                            TServer: {
                                wrap-up-time: "0"
                            }
                       }
                       state: "1"
                       switchDBID: "101"
                       loginCode: "111"
                },
                {
                       useOverride: "2"
                       tenantDBID: "1"
                       DBID: "263"
                       switchSpecificType: "1"
                       userProperties: {
                            provisioning_flags: {
                                modified_At: "4ac7b1ad-ac79-4f7b-a082-317ea79fc667"
                            }
                            TServer: {
                                wrap-up-time: "0"
                            }
                       }
                       state: "1"
                       switchDBID: "101"
                       loginCode: "123456789"
                }
        ]
}

Or you can get a specific object by a database ID. For example, let's get the CfgAgentLogin with a DBID of 261:

Request

GET http://198.51.100.10:8080/api/v2/platform/configuration/agent-logins/261

Response

{
   statusCode: 0
   agent-login: {
                      useOverride: "2"
                      tenantDBID: "1"
                      DBID: "261"
                      switchSpecificType: "1"
                      userProperties: {
                           TServer: {
                               wrap-up-time: "0"
                           }
                      }
                      state: "1"
                      switchDBID: "101"
                      loginCode: "111"
               }

}

POST Operations

To add a new object, make sure the Content-Type header is set to application/json. Your POST must include the full JSON representation of the object as it's required by Configuration Server.

For example:

Request

POST  http://198.51.100.10:8080/api/v2/platform/configuration/agent-logins
{
      "agent-login": {
             "useOverride": "2", 
             "tenantDBID" : "1", 
             "switchSpecificType": "1",
             "userProperties": 
                     {"TServer": {"wrap-up-time": "0"}}, "state": "1", "switchDBID": "101", "loginCode": "111"}
}

You can find details about the configuration objects in Introduction to the Configuration Layer Objects.

PUT Operations

To update a configuration object, you need to include the corresponding Configuration Server delta structure. For example, to update a CfgSkill you need to include the CfgDeltaSkill.

Important

The URI naming format for delta objects is the same as the other configuration objects: the name in lower case, with each word separated by a hyphen (-). For example, CfgDeltaSkill would be "delta-skill".

You don't need to include the DBID in the delta structure because it's ignored — GWS uses the DBID that's passed in the URI instead.

Here's an example of how to update a configuration skill with a DBID of 218 by sending the delta structure:

Request

PUT http://198.51.100.10:8080/api/v2/platform/configuration/skills/218
{ 
     "delta-skill": { 
            "CfgSkill": {
                   "name":"NewName"
              } 
     }
}

DELETE Operations

DELETE operations work on a URI with a DBID and don't require any additional parameters. For example:

Request

DELETE http://198.51.100.10:8080/api/v2/platform/configuration/agent-logins/261

Limitations

There is no contact center segmentation yet for objects that GWS reads directly from Configuration Server.