Configuring JSON response handling
If you are adding an integration that also needs to return a response to Sinch Contact Pro, you can find the options for configuring how the JSON response is handled in the tables below.
You can configure several operations in the same event-driven integration (for example, set preferred agent and save conversation attached data).
Response configuration
Name | Parent object | JSON data type | Description | Example values |
---|---|---|---|---|
set | - | object | Parent object for set operation definitions | - |
priority | set | string |
Specifies either the name of an element in the response JSON body or the name of a response header whose value should be used to set a new priority value for the associated contact You can also use static values instead. Expected value: an unsigned integer or a value convertible to an unsigned integer. |
Response body data
received:
JSON configuration:
|
queue | set | object |
Specifies either the name of an element in the response JSON body
or the name of a response header whose value should be used to
set a new queue for the contact. The new queue can be specified
using one of the following:
Expected value:
UUID supports uppercase or lowercase, and can optionally include hyphens. |
Configuration for:
Expected (part of) response body data:
Configuration for:
Expected (part of) response body data:
|
preferredAgent | set | object |
Specifies either the name of an element in the response JSON body or the name of a response header whose value should be used to set the preferred agent for the contact. Expected value: a non-empty string based on which an individual agent can be identified This can be:
|
Configuration
Expected (part of) response body data:
|
requiredAgents | set | object |
Specifies which parts of data within response payload should be extracted and used to set required agents and required agent timeout for the conversation. Expected value: For the element containing required agent identifiers, the value is expected to be a list of non-empty strings where each string should contain data with which an individual agent can be identified. This can be:
The value of the element containing required agent timeout is expected to be an unsigned integer or a value convertible to an unsigned integer. You can also use static values instead. |
Configuration Response payload contains an array of strings (chat addresses) and timeout:
Expected (part of) response body data:
Configuration Response body contains an array of objects:
Expected response body data:
|
save | - | object |
Specifies the parts of data in the response payload that should be extracted and added as conversation attached data (CAD) and the structure for storing the data. You can also use static values instead (or in conjunction with data extracted from response payload). Data can be extracted from either response headers or response JSON body, and may also be configured to include, for example, request duration and response HTTP status code as debug information. |
See examples Fetch data from an external system and show it to the agent and Analyzing an email with ChatGPT and saving the analysis as CAD. |
Response object
Name | JSON data type | Placeholder syntax | Description |
---|---|---|---|
Headers: All header names and values | object | null |
{response.headers} {response.headers.*} |
All response header names and their values as a JSON object (with header names in lower case) or null if the response didn't contain header data Example:
|
Headers: A single header value | string | null |
{response.headers.<header-name>} |
The value of a single response header named <header-name> or null if response header with the specified name does not exist. To refer to the value of the header with name x-cloud-trace-context, use syntax {response.headers.x-cloud-trace-context} . Note:
Header name lookup is case insensitive. |
Body: Complete (JSON) | any |
{response.body} {response.body.*} |
Complete response body data in deserialized format if the data is
in valid JSON format, null
otherwise. Example:
|
Body: A single named element value (JSON) | any |
{response.body.<element-name>} {response.body.<element-name>.<sub-element-name>} |
The value of a single JSON object property in deserialized format, or null if no such named element exists in the response body object hierarchy. Element search path components are delimited using the dot character (.). To refer to the body property with name detections in the above example, use syntax {response.body.detections}. Note:
If the element names in the search path contain dot characters, enclose the names in escaped double quotes (for example, {response.body.\"foo.bar\"}) . |
Body: Single array element value (JSON) | any |
{response.body[<element-index>]} {response.body.<element-name>[<sub-element-index>]} |
The value of a single element contained by the specified body element of array type, as indicated by the zero-based element index enclosed in square brackets For example, to refer to the first element in an array, use syntax [0]. The value resolves as null if one of the following is true:
To refer to the first element of the body property with name detections in the above example, use syntax {response.body.detections[0]}. To refer to the confidence property of that element, use syntax {response.body.detections[0].confidence}. Note:
To refer to the last element of the array without knowing the size of the array beforehand, use element index value -1. Note:
If the element names in the search path contain dot characters, enclose the names in escaped double quotes (for example, {response.body.\"foo.bar\"}) . |
Body: Complete (non-JSON) | string | null | {response.text} | Complete response body data if the data is not in valid JSON format (for example, plain text, HTML, or XML), null otherwise. |
Status code | number | {response.status} | The numeric HTTP status code of the response (for example, 200, 404) |
Duration | number | {response.duration} | The number of seconds it took to process the request and response, from starting to establish the connection with the remote server to having received all the response data from the server. The value includes fractions of seconds according to the resolution of the system performance counters, which may be limited by the maximum precision of Python's float type (for example, 2.3970600999999998). |
Supported events for operations
Event | Chats (in) | Chats (out) | Queue calls (in) | Direct calls (in) | Direct calls (out) | Campaign calls | Emails |
---|---|---|---|---|---|---|---|
Received | |||||||
Queued | |||||||
Allocated | |||||||
Accepted | |||||||
Rejected | |||||||
Transferred | 1 | 1 | |||||
Forwarded | 1 | 1 | |||||
Ended | |||||||
Abandoned |
1 Only when the event is the initial trigger event after successful internal call forward (by a queue) or transfer (by an agent).
Event | Chats (in) | Chats (out) | Queue calls (in) | Direct calls (in) | Direct Calls (out) | Campaign calls | Emails |
---|---|---|---|---|---|---|---|
Received | |||||||
Queued | |||||||
Allocated | |||||||
Accepted | - | ||||||
Rejected | |||||||
Transferred | 1 | ||||||
Forwarded | 1 | ||||||
Ended | |||||||
Abandoned |
1 Only when the event is the initial trigger event after successful internal call forward (by a queue) or transfer (by an agent).
Event | Chats (in) | Chats (out) | Queue calls (in) | Direct calls (in) | Direct calls (out) | Campaign calls | Emails |
---|---|---|---|---|---|---|---|
Received | |||||||
Queued | |||||||
Allocated | |||||||
Accepted | |||||||
Rejected | |||||||
Transferred | 1 | ||||||
Forwarded | 1 | ||||||
Ended | |||||||
Abandoned | - |
1 Only when the event is the initial trigger event after successful internal call forward (by a queue) or transfer (by an agent).
Event | Chats (in) | Chats (out) | Queue calls (in) | Direct calls (in) | Direct calls (out) | Campaign calls | Emails |
---|---|---|---|---|---|---|---|
Received | |||||||
Queued | |||||||
Allocated | |||||||
Accepted | |||||||
Rejected | |||||||
Transferred | |||||||
Forwarded | |||||||
Ended | |||||||
Abandoned |
Event | Chats (in) | Chats (out) | Calls (in) | Calls (out) | Campaign calls | Emails |
---|---|---|---|---|---|---|
Received | ||||||
Queued | 2 | 2 | ||||
Allocated | ||||||
Accepted | ||||||
Rejected | ||||||
Transferred | 1 | |||||
Forwarded | 1 | |||||
Ended | ||||||
Abandoned |
: Saving CAD is fully supported. CAD is saved and shown in Communication Panel.
: Saving CAD is partially supported. CAD is saved but not shown in Communication Panel.
: Saving CAD is not supported.
1 Only when the event is the initial trigger event after successful internal call forward (by a queue) or transfer (by an agent).
2 CAD is still not shown in some specific cases, such as when the conversation is allocated to an agent immediately after arriving in the queue, and the agent accepts the offered conversation so that it doesn't return to the queue due to, for example, allocation timeout.
Priority of set operations in the Contact Pro system
The set operations defined with EDI have the highest priority in the Sinch Contact Pro system. This means that they overwrite potential corresponding operations from other contexts, such as:
-
For chats, required or preferred agents set by queue configuration
-
For calls, priority set by custom IVR
-
For emails, required or preferred agents set by queue configuration orContact Center customizers, and contact priority set by email keyword rules
Exceptions are:
-
Required agent(s) are never overwritten by preferred agents.
-
An email queue set by either email keyword rules or a Contact Center customizer always overrides any set queue operation of an event-driven integration.