Filters
Filters are used to determine which conversations the request should apply to or get, filters use conversation metadata to only apply to or get conversations that match the filter's specific metadata conditions. Using Group Filters a filter can be as complex as necessary in order to apply the request to or get the exact conversations you need. You may be familiar with the filter rules used in the U-Capture application, used to search for conversations, apply policies to specific calls, etc. As you would expect filters in the APIs work in the same way except the terminology is a little different.
In this article, see information to help build your understanding of how Filters work to various levels of complexity, as well as see a full list of filter parameters and valid values:
Filter Basics
A filter defines what type of data you want to filter by (fieldName
), what condition the filter should regard as a match (operator
), and what data value you want to filter for (stringValue
), for filters using a fieldName
that requires a date and time to be specified there's also timestampValue
- using these parameters you can apply your request to or get conversations with specific metadata values, for example you could find conversations where the agent's extension contains "384":
"groupFilter": { "leftFilter": { "fieldName": "agent.extension", "operator": "CONVERSATION_FILTER_OPERATOR_CONTAINS", "stringValue": "384" } },
Group Filters
Group filters use the logic above but can combine multiple filters to match conversations with multiple conditions, for example where more than one data type matches specific conditions, or the same data type matches two specific conditions. Group filters combine filters using AND/OR operators, and use leftFilter
and rightFilter
array parameters to differentiate them.
The simple graphic below illustrates how each of them work. In this example you have three searches – A, B, and C.

When you apply an AND you’re basically saying the conversation must match everything you’re searching for in A AND B AND C (the piece in the middle where all three circles overlap).
When you apply an OR you’re basically saying the recording can match anything you’re searching for in A OR B OR C (anywhere, in any circle).
You can apply the AND and OR operators to multiple conditions as well as filters.
For example, you could apply the request to conversations to/from the Sales Team AND Pre-Sales Team:
"groupFilter": { "leftFilter": { "fieldName": "agent.department", "operator": "CONVERSATION_FILTER_OPERATOR_EQUAL", "stringValue": "Sales"} }, "operator": "CONVERSATION_LOGICAL_OPERATOR_AND" "rightFilter": { "fieldName": "agent.department" "operator": "CONVERSATION_FILTER_OPERATOR_EQUAL" "stringValue": "Pre-Sales" } },
Nested Group Filters
Group filters can also contain other group filters for even more precision and flexibility, this works by nesting group filters. Whenever you group a set of filters together using AND/OR, you’re basically saying search for all these things first and provide the result, then combine the result with any other filters that you have defined further down in the groupFilter
.
Nested group filters use left and right parameters to differentiate them, similar to group filters, but use leftGroupFilter
and rightGroupFilter
to indicate that they are nested. In the example below you can see that groupFilter
contains a leftGroupFilter
, a rightGroupFilter
and an operator
- as these are nested you can see that leftGroupFilter
and rightGroupFilter
each contain an operator
and another leftGroupFilter
/ rightGroupFilter
pair each with their own leftFilter
.
Following this nested logic you can create a very precise filter - in the example below, I filtered for all calls from two agents using OR, then grouped a department filter (Sales
) and a Call Direction filter (CONVERSATION_DIRECTION_OUTGOING
) with AND to give me all Outgoing calls from the Sales department, using OR at the top means my results would provide all calls by either agent (Agent 384713 OR Agent 606939) as well as any outgoing sales calls.
Logical expression: (agent.id EQUAL 384713 OR agent.id EQUAL 606939) OR (callProperties.department EQUAL sales AND callProperties.callDirection EQUAL CONVERSATION_DIRECTION_OUTGOING)
"groupFilter": { "leftGroupFilter": { "leftGroupFilter": { "leftFilter": { "fieldName": "agent.id", "operator": "CONVERSATION_FILTER_OPERATOR_EQUAL", "stringValue": "384713" } }, "operator": "CONVERSATION_LOGICAL_OPERATOR_OR", "rightGroupFilter": { "leftFilter": { "fieldName": "agent.id", "operator": "CONVERSATION_FILTER_OPERATOR_EQUAL", "stringValue": "3606939" } } }, "operator": "CONVERSATION_LOGICAL_OPERATOR_OR", "rightGroupFilter": { "leftGroupFilter": { "leftFilter": { "fieldName": "callProperties.department", "operator": "CONVERSATION_FILTER_OPERATOR_EQUAL", "stringValue": "Sales" } }, "operator": "CONVERSATION_LOGICAL_OPERATOR_AND", "rightGroupFilter": { "leftFilter": { "fieldName": "callProperties.callDirection", "operator": "CONVERSATION_FILTER_OPERATOR_EQUAL", "stringValue": "CONVERSATION_DIRECTION_OUTGOING" } } } },

Parameters
Parameter Name | Data Type | Description | Required/Optional |
---|---|---|---|
| Array | Contains the entire filter details. | Required |
| Array | The first set of filters if you are using nested group filters, can contain The nested | Optional |
| Array | The second and and subsequent set of filters if you are using nested group filters, can contain The nested | Optional |
| Array | The details of each simple filter. In a simple set of filters | Required |
| Array | The details of the second filter in a simple set of filters. | Optional |
| String | The type of metadata you want to filter by, for a list of valid values, what they mean and any conditions they have, see fieldName Values. | Required |
| String | How the group filter or filter operates:
| Required |
| String | What data value you want to filter for. For example, if I wanted to get conversations by any agent in the Sales team, I would use | Optional |
| Date-Time | The date and time you want to specify, used for filters that require a date. In the format | Optional |
fieldName
Values
As mentioned above, fieldName
is the type of metadata you want to filter by - valid options, what they mean, and any specific conditions are detailed in the table below.
Valid | Description |
---|---|
| Configurable metadata field that can be mapped, No default mapping. |
| The email of the recorded agent. |
| The first name of the recorded agent. |
| The ID of the recorded agent. |
| The last name of the recorded agent. |
| Location information for the recorded agent/device (if available). |
| The manager of the recorded agent. |
| Call audio status - either |
| The direction of the call, either |
| Details of the call type (if available). |
| The unique ID of the conversation, used to track the conversation and tie the conversation data together throughout the system. Use this |
| The department that the recorded agent is part of. |
| The ID of the recorded device. |
| The date and time that conversation capture ended, metadata is in the format |
| The extension of the recorded agent. |
| The group the call was directed to. |
| The integration number the conversation belongs to. |
| The status of the license for the conversation, either |
| If the conversation is licensed or not, either |
| The local name of the agent in the conversation, usually their full name or alias. |
| The number assigned to the agent, note that this is not their phone number. |
| A list of details for the other parties in the captured conversation. |
| Details on the screen recording status associated with the conversation, either |
| Physical network information for the conversation at SIP level. |
| The date and time that conversation capture started, metadata is in the format Y |
| Name of the Trunk (if available). |