For a quick overview of the search API and how to use our documentation, refer the video below:

anchorWatch Getting Started With the Search API

Watch: Getting Started with the /search API

anchorIntroduction

A GraphQL API enables clients to construct queries to retrieve data. The queries are defined by the API server in the form of a GraphQL schema, which acts as a contract between the server and the client.

Note: For an introduction to GraphQL, refer : GraphQL - 101

The API allows access to the following:

1. Task related data stored as Customer Session Records (CSRs) and Customer Activity Records (CARs), accessible using the taskDetails graphql query.

2. Agent related data stored as Agent Session Records (ASRs) and Agent Activity Records (AARs), accessible using the agentSession graphql query.

3. Queue related data stored as Call Leg Records (CLRs), accessible using the taskLegDetails graphql query

Based on the operation, a query can be of two types:

1. Query to fetch raw data: fetching individual records stored, such as CSRs, ASRs, CARs, etc., with the ability to filter on data and apply pagination to get more records. In SQL terminology, this operation is analogous to

   SELECT id, channelType FROM task WHERE channelType='telephony'

   The structure of such a query is shown below

   

2. Query to perform aggregations: performing aggregation operations on record fields with support for group-bys, filtering, and pagination. In SQL terminology, the API is capable of the following queries:

   • SELECT COUNT(id), MAX(totalDuration) FROM task

   • SELECT AVG(connectedDuration), AVG(totalDuration) FROM task GROUP BY teamId, siteId

   • SELECT MAX(holdDuration) FROM task WHERE channelType='telephony' GROUP BY lastAgent.id

   The structure of such a query can be found below

   

The following sections describe each query and supported operations in detail.

anchorQuery Definitions

The following sections describe the query types supported in detail.

TaskDetails Query

A taskDetails query operates over CSR and CAR records.

Sample Query

A sample query to fetch tasks created on 1st January 2023

{
  taskDetails(
    from: 1672531200000 # 1st January 2023 00:00:00 UTC
    to: 1672617599000 # 1st January 2023 23:59:59 UTC
  ) {
    tasks {
      id # Scalar field
      isActive
      channelType
      createdTime
      endedTime
      lastAgent {
        # Object / Composite field
        id # Scalar field
      }
    }
  }
}

Note: Scalar fields are atomic and represent indivisible values, these are basic data types like Int, Long, String, Boolean, Float. Object fields are defined by the graphQL schema and contain other fields within them.Refer GraphQL documentation for Scalar types, type system and objects

GraphQL Schema

The GraphQL schema structure is defined as given below.

taskDetails(
    from: Long!  # MANDATORY ARGUMENT
    to: Long!    # MANDATORY ARGUMENT
    timeComparator: QueryTimeType
    filter: TaskDetailsFilters
    extFilter: TaskDetailsSpecificFilters
    aggregations: [TaskV2Aggregation]
    aggregationInterval: IntervalData
    pagination: Pagination
): TaskDetailsList

Arguments

1. from - Mandatory argument: accepts a Long value representing the epoch timestamp, which defines the start of the query span. By default, the createdTime field is used for comparison, but this can be overridden to use endedTime by using the timeComparator argument.

2. to - Mandatory argument: accepts a Long value representing the epoch timestamp, which defines the end of the query span. By default, the createdTime field is used for comparison, but this can be overridden to use endedTime by using the timeComparator argument.

3. timeComparator - Optional argument: accepts a value of the QueryTimeType type. This defines the field which from and to arguments use for retrieving documents. Accepted values are createdTime and endedTime.

4. filter - Optional argument: accepts a TaskDetailsFilters object. This is used to filter results based on a criteria defined on CSR fields. Refer to the filtering section for more details.

5. extFilter - Optional argument: accepts a TaskDetailsSpecificFilters object. This is used to filter results based on a criteria defined on CAR fields. Refer to the filtering section for more details.

6. aggregations - Optional argument: accepts a List of TaskV2Aggregation. This is used to perform aggregations over data. Refer to the aggregations section for more details.

7. aggregationInterval- Optional argument: accepts an IntervalData object. This is used when time-based aggregation needs to be performed. Refer to the aggregations section for more details.

8. pagination - Optional argument: accepts an object of Pagination object. This is used to perform pagination. Refer to the pagination section for more details.

Some sample queries can be found below

AgentSession Query

An agentSession query operates over ASR and AAR records.

Sample Query

A sample query to fetch agentSessions created on 1st January 2023.

{
  agentSession(
    from: 1672531200000 # 1st January 2023 00:00:00 UTC
    to: 1672617599000 # 1st January 2023 23:59:59 UTC
  ) {
    agentSessions {
      agentId # Scalar field
      teamId
      siteId
      startTime
      endTime
      channelInfo {
        # Object / Composite field
        channelId
        channelType # Scalar field
        totalDuration
        connectedDuration
      }
    }
  }
}

GraphQL schema

The GraphQL schema structure is defined as given below.

agentSession(
    from: Long! # MANDATORY ARGUMENT
    to: Long!   # MANDATORY ARGUMENT
    filter: AgentSessionFilters
    extFilter: AgentSessionSpecificFilters
    aggregations: [AgentSessionV2Aggregation]
    aggregationInterval: IntervalData
    pagination: Pagination
): AgentSessions

Arguments

1. from - Mandatory argument: accepts a Long value representing epoch timestamp which defines the start of the query span, the startTime field is used for comparison.

2. to - Mandatory argument: accepts a Long value representing the epoch timestamp, which defines the end of the query span; the startTime field is used for comparison.

3. filter - Optional argument: accepts an AgentSessionFilters object. This is used to filter results based on user-defined criteria on ASR fields. Refer to the filtering section for more details.

4. extFilter - Optional argument: accepts an AgentSessionSpecificFilters object. This is used to filter results based on user-defined criteria on AAR fields. Refer to the filtering section for more details.

5. aggregations - Optional argument: accepts a List of AgentSessionV2Aggregation, This is used to perform aggregations over data. Refer to the aggregations section for more details.

6. aggregationInterval- Optional argument: accepts an IntervalData object. This is used when time-based aggregation needs to be performed. Refer to the aggregations section for more details.

7. pagination - Optional argument: accepts an object of Pagination object. This is used to perform pagination. Refer to the pagination section for more details.

Sample query to fetch ASR fields can be found [here](https://github.com/WebexSamples/webex-contact-center-api-samples/tree/main/reporting-samples/graphql-sample/agentSession/Raw Data Fetching/Simple query.graphql), the response for the same is [here](https://github.com/WebexSamples/webex-contact-center-api-samples/tree/main/reporting-samples/graphql-sample/agentSession/Raw Data Fetching/Simple query-response.json).

TaskLegDetails Query

An taskLegDetails query operates over CLR data.

Note: The TaskLegDetails object is a part of Queue Based Reporting Early Access, and will only return data if you are a member of the Early Access Program.

Sample Query

A sample query to fetch taskLegs for a particular task on 1st January 2023

{
  taskLegDetails(
    from: 1672531200000 # 1st January 2023 00:00:00 UTC
    to: 1672617599000 # 1st January 2023 23:59:59 UTC
    filter: { taskId: { equals: "2d6ef583-4a57-40ec-83b4-390d14625e19" } }
  ) {
    taskLegs {
      id
      taskId
      queue {
        name
      }
      handleType
    }
  }
}

GraphQL schema

The GraphQL schema structure is defined as

taskLegDetails(
    from: Long! # MANDATORY ARGUMENT
    to: Long!   # MANDATORY ARGUMENT
    timeComparator: QueryTimeType
    filter: TaskLegDetailsFilters
    aggregations: [TaskLegV2Aggregation]
    aggregationInterval: IntervalData
    pagination: Pagination
): TaskLegDetailsList

Arguments

1. from - Mandatory argument: accepts a Long value representing the epoch timestamp which defines the start of the query span, By default, the createdTime field is used for comparison, but this can be overridden to use endedTime by using the timeComparator argument.

2. to - Mandatory argument: accepts a Long value representing epoch timestamp which defines the end of the query span, By default, the createdTime field is used for comparison, but this can be overridden to use endedTime by using the timeComparator argument.

3. timeComparator - Optional argument: accepts a value of QueryTimeType type. This defines the field which from and to arguments use for retrieving documents. Accepted values are createdTime and endedTime.

4. filter - Optional argument: accepts an TaskLegDetailsFilters object. This is used to filter results based on user-defined criteria. Refer to the filtering section for more details.

5. aggregations - Optional argument: accepts a List of TaskLegV2Aggregation. This is used to perform aggregations over data. Refer to the aggregations section for more details.

6. aggregationInterval- Optional argument: accepts an IntervalData object. This is used when time-based aggregation needs to be performed. Refer to the aggregations section for more details.

7. pagination - Optional argument: accepts an object of Pagination object. This is used to perform pagination. Refer to the pagination section for more details.

anchorSupport for Filtering data

Filtering of data is supported using the filter and extFilter arguments. Filtering is supported in both operations, fetching raw data or performing aggregations; the syntax for defining the filter criteria remains the same.

The distinction between filter and extFilter is the type of fields they allow filtering on. In a taskDetails query, filter is used for filtering data based on fields available in a CSR record, and extFilter is used for filtering data based on fields available in a CAR record. Similarly, in an agentSession query, filter is used for filtering based on ASR fields and extFilter is used for filtering based on AAR fields. In a taskLegDetails query, extfilter is not supported and filter can be used to filter data based on CLR fields.

The general formula or syntax for filtering is

filter : {
    fieldName : { operator : value }
}

Filtering based on Scalar fields

Based on the data type different filter operators are available

String Operators for filtering

The following operators are supported for String fields

Given below is a sample for filtering using equals operator, equals can be replaced with notequals.

filter: {
    origin: { equals: "+12344565678" }
}

match operator can be used filter based on a regex/pattern.

filter: {
    origin: { match: "+12345678.+" }
}

contains operator to filter on a substring match of a string field

filter: {
    campaignName : { contains : "Sales"}
}

Numerical Operators for filtering

The following operators are supported for numerical fields

Using the compound operator and and numerical operators we can build range filter as given in below sample.

filter: {
    and: [
        { totalDuration: { lte: 120000 } }
        { totalDuration: { gte: 60000 } }
    ]
}

Compound operators for filtering

Compound filters include 2 operators - and & or operator, these accept multiple filter criterion in the form of a list.

Fetch records where channelType is telephony and status is either created or ended

    filter: {
      and: [
        { channelType: { equals: telephony } }
        {
          or: [
            { status: { equals: "ended" } }
            { status: { equals: "created" } }
          ]
        }
      ]
    }

Some sample queries using compound operators are given below.

Filtering based on Composite objects

Filtering is only supported for scalar fields and not for objects; however, scalar fields inside objects can be filtered.

Consider a scenario where filtering is performed on the subject field within the email object, which is nested inside the top-level channelMetaData field. The structure of the query reflects this hierarchy, starting from the top-level field and traversing through subfields until reaching the leaf field.

filter: {
    channelMetaData: {
        email: { subject: { equals: "sample subject" } }
    }
}

Since all the CAR and AAR fields are present in the activities object, filtering using extFilter also follows the same pattern, one such sample is given below

extFilter : {
    activities : {
        nodes : {
            queueId : {equals : "40162355-72f4-4dc1-b710-2f8c94e5d14b"}
        }
    }
}

Some samples for filtering on object types are given below

Fields supported for filtering

Refer data dictionary for fields supporting filtering.

anchorPerforming Aggregations

Any query with the aggregations argument is treated as an aggregation query; this argument accepts a list of objects.

Each object requires the following mandatory arguments :

1. field - String, denotes the identifier or field name on which the aggregation needs to be done.
2. name - String, identifier to determine the result of the aggregation operation.
3. type - Enum, defines the aggregation operation; depending on the data type of the field specified, the following aggregations are supported.

The following arguments are optional :

1. filter - Denotes the filter criteria for documents for the particular aggregation.

2. predicate - Applicable only for global variables, Refer to the Global Variable section for more details.

Refer below for the syntax of aggregations argument.

aggregations: [
  {
     field: "totalDuration"
     type: max
     name: "maxDurationTelephony"
  }
]

Sample queries to perform aggregations on various data types are given below.

Performing group by operation

To perform a group by operation, the fields required for group bys should be included in the requested fields. The below sample performs a group by on the lastAgent.id field.

{
  taskDetails(
    from: 1617401436000
    to: 1619647836000
    aggregations: [
      {
        field: "totalDuration"
        type: max
        name: "maxDurationTelephony"
        filter: { channelType: { equals: telephony } }
      }
    ]
  ) {
    tasks {
      lastAgent {
        id # Group by on lastAgent.id
      }
      aggregation {
        name
        value
      }
    }
  }
}

Some sample queries to perform group by on various data types.

Interval based group bys.

Aggregations can be grouped based on time intervals such as DAILY , WEEKLY etc. by adding the intervalStartTime as a requested field and using the aggregationInterval argument, which accepts two parameters.

• interval - Mandatory argument: accepts an Enum, Based on the query span (i.e. difference of the values passed in from and to) the following values are supported.

• timezone - Optional argument: accepts a String representing the timezone, using which the intervals should be formed; the default timezone used is UTC.

Refer the below sample syntax for the aggregationInterval argument.

aggregationInterval : {
    interval : DAILY
    timezone : "America/New_York"
}

Sample queries to perform interval based aggregations.

Note: The number of fields used for a group by operation in an aggregation query cannot exceed 10.

Pagination support

When using group bys, the data can be paginated to get more results, using the pagination argument. Refer to the Pagination section for more details.

Support for filtering within Aggregation

In an aggregation query, filters can be applied for all the aggregations or for individual aggregations, which are referred to as global filters and sub-filters respectively.

When filtering has to be applied to all aggregations, the top-level filter and extFilter arguments can be used. Refer to the Filtering section for more details on the syntax and usage. Refer to the below general syntax for global filtering support.

filter : {
    lastTeam : {
        name : {equals : "team1"}
    }
},
aggregations: [
    {
        field: "id"
        type: count
        name: "count of ids"
    },
    {
        field: "totalDuration"
        type: average
        name: "average of totalDuration"
    }
]

Sample queries to perform aggregations with filter criteria on various data types are given below.

Aggregations with sub filters

Filtering can also be done for individual aggregation using the filter and extfilter argument in the aggregation object. Refer below general syntax for sub-filter support

aggregations: [
  {
     field: "totalDuration"
     type: max
     name: "maxDurationTelephony"
     filter: { channelType: { equals: telephony } }
  }
]

Sample queries to perform aggregations with sub-filter criteria on various data types are given below.

Fields supported for aggregations

Refer data dictionary for fields supporting aggregation.

anchorFetching Raw Data

Fields from individual records can also be fetched; this is referred to as fetching raw data. Any query without the aggregations argument is treated as a query to fetch raw data.

Based on the fields that are requested and the filter criteria specified in the query, the API will read data from the appropriate type of record and return the requested field for each record. It is recommended to fetch fields belonging to the same type of record. Refer to the data dictionary section for more details.

Sample taskDetails query to fetch id field in a taskDetails query.

{
  taskDetails(from: 1644859375000, to: 1671038575000) {
    tasks {
      id
    }
  }
}

Note: When fetching AAR and CAR data, the query span i.e. from and to cannot exceed more than 30 days

Samples for various data types are given below

Filtering data

To fetch data matching a filter criteria, the filter and extFilter arguments can be used. Refer section on filtering for details

Sorting Support

When fetching raw data, the data can be sorted in ascending or descending order. Fields supporting sorting accept a sort argument where the sorting criteria can be specified as asc for ascending and desc for descending. The below sample sorts data in ascending order of "createdTime" field.

{
  taskDetails(from: 1644859375000, to: 1671038575000) {
    tasks {
      id
      createdTime(sort: asc)
    }
  }
}

Refer to the data dictionary for fields supporting sorting. Sample queries to fetch data with sorting are given below.

Pagination support for fetching raw data

Pagination is supported for raw queries, Refer section on pagination for details

anchorPagination Support

The search API supports pagination for both operations: performing aggregations and fetching raw data. The page size/ number of records returned by the query is fixed. Clients can fetch the next set of records using the hasNextPage and the endCursor fields in the response.

{
  taskDetails(from: 1690964812000, to: 1691224012000) {
    tasks {
      id
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

hasNextPage is a boolean field that determines if more data exists for the given query. If the hasNextPage value is true, clients can fetch the value of the endCursor field, which is a string and acts as an identifier for the next page. endCursor value is passed in the subsequent query to fetch the next set of records.

The pagination argument accepts the cursor input parameter, which accepts the endCursor value and fetches the next page. A sample is given below.

{
  taskDetails(
    from: 1690964812000
    to: 1691224012000
    pagination: { cursor: "<VALUE-OF-endCursor-FROM-PREVIOUS-QUERY" }
  ) {
    tasks {
      id
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

The page size of a query depends on the query type and the operations, these are given below.

Note: In order to fetch the first page, the pagination argument can either be omitted or the cursor value can be set to NA.

Sample queries demonstrating pagination when fetching raw data are given below.

Inner Pagination / Paginating CAR and AAR records

Both CAR and AAR records are exposed within the activities.nodes field, which provides a list of records. To fetch more CAR and AAR records, inner pagination can be used; this enables pagination within the records instead of paginating the records themselves.

To fetch more records within activities.nodes , the cursor can be retrieved from the activities.pageInfo field, which contains the endCursor and hasNextPage fields. This cursor value can be passed into the after argument.

The activities field supports the following two arguments to support inner pagination

1. first - Accepts an Int value which determines the number of records to be fetched. By default, the value is set to 25 and the maximum supported value is 100.

2. after - Accepts a String value which determines the next page to be fetched.

Note: The total count of records can be read using the activities.totalCount field.

Note: Since inner pagination enables record level pagination, the cursor value retrieved from a record is not applicable for other records, hence it is highly recommended to use a filter to exclude the other records.

A sample query to fetch next 5 CAR records for task id 9bd2d70a-3438-4784-b9fd-83e263538393 after the cursor value of 1697205941011 is shown below

{
  taskDetails(
    from: 1696118400000
    to: 1697328000000
    filter: { id: { equals: "9bd2d70a-3438-4784-b9fd-83e263538393" } }
  ) {
    tasks {
      id
      activities(first: 5, after: "1697205941011") {
        totalCount
        nodes {
          id
          eventName
        }
        pageInfo {
          hasNextPage
          endCursor
        }
      }
    }
  }
}

Sample queries for inner pagination of CAR and AAR are given below.

Pagination Support for Aggregation with Group Bys

In case of aggregation queries involving group bys, pagination can be done to fetch more records. Sample queries are given below.

anchorGlobal Variables Support

Global variables are exposed as part of the TaskDetails and TaskLegDetails queries. Depending on the data type of the variable, the following 5 types of global variables are stored and can be fetched:

1. stringGlobalVariables

2. booleanGlobalVariables

3. integerGlobalVariables

4. doubleGlobalVariables

5. longGlobalVariables

To fetch the global variable data, pass the name of the global in the argument Eg: To get data of the Global Variable of String Type with name as GlobalVariable1

# 'name' argument is mandatory.
#  This block will fetch name and value for the stringGlobalVariable named 'GlobalVariable1'
stringGlobalVariables(name: "GlobalVariable1") {
    name
    value
}

Multiple global variables of the same type can be fetched using aliasing:

# To fetch multiple global variables use aliasing - https://graphql.org/learn/queries/#aliases
GV1: stringGlobalVariables(name: "GV1") {
    name
    value
}
GV59: stringGlobalVariables(name: "GV59") {
    name
    value
}

Some sample queries on globalVariables for taskDetails and taskLegDetails

Filtering based on global variables

Filtering on global variables is supported by passing the global variable name in the name argument and values to be filtered in the value argument. Eg: Fetch the records Global Variable (GV1) of string with value ABC123

{
    stringGlobalVariables: {
        name: { equals: "GV1" }
        value: { equals: "ABC123" }
    }
}

Eg: Fetch the records Global Variable (GV2) of integer type greater than 100

{
    integerGlobalVariables: {
        name: { equals: "GV2" }
        value: { gt: 100 }
    }
}

Refer section on filtering for different operators supported.

Some sample queries on global variables with filtering for taskDetails and taskLegDetails

Performing Aggregations on global variables

For performing aggregation on global variables we need to use the predicate argument in the aggregations object Eg: Sum of all values of integer global variable named GV2 .

 {
    field: "integerGlobalVariables.value"
    name: "Sum of GV2"
    type: sum
    # Predicate is used to define which global variable needs to be considered for the operation.
    predicate: { integerGlobalVariables: { name: { equals: "GV2" } } }
}

Eg: Fetch unique value of a string global variable named GV1.

 {
    field: "stringGlobalVariables.value"
    name: "Unique of GV1"
    type: cardinality
    # Predicate is used to define which global variable needs to be considered for the operation.
    predicate: { stringGlobalVariables: { name: { equals: "GV1" } } }
}

Refer section on aggregation for more details on aggregation types.

Some sample aggregations on globalVariables for taskDetails and taskLegDetails

Performing group by operation on global variables

For performing group by's using global variables, the fields required for group bys should be included in the requested fields, The sample below performs a group by operation on the value of a string global variable named Global_Language.

{
  # Group by using  Global Variables
  # To perform a group by on a global variable add the global variable in the selection set.
  taskDetails(
    from: 1655449155512
    to: 1671038575000
    aggregations: [
      { field: "id", name: "count of calls", type: count }
      {
        field: "integerGlobalVariables.value"
        name: "Sum of GV2"
        type: sum
        predicate: { integerGlobalVariables: { name: { equals: "GV2" } } }
      }
    ]
  ) {
    tasks {
      # Group by on stringGlobalVariable named "Global_Language".
      stringGlobalVariables(name: "Global_Language") {
        value
      }
      aggregation {
        name
        value
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Using aliasing group by can be done on multiple global variables of the same type.

{
  # Group by using  Global Variables
  # To perform a group by on a global variable add the global variable in the selection set.
  taskDetails(
    from: 1655449155512
    to: 1671038575000
    aggregations: [
      { field: "id", name: "count of calls", type: count }
      {
        field: "integerGlobalVariables.value"
        name: "Sum of GV2"
        type: sum
        predicate: { integerGlobalVariables: { name: { equals: "GV2" } } }
      }
    ]
  ) {
    tasks {
      # Group by on stringGlobalVariable named "Global_Language".
      stringGlobalVariables(name: "Global_Language") {
        value
      }
      # Group by on stringGlobalVariable named "Location".
      Location: stringGlobalVariables(name: "Location") {
        value
      }
      aggregation {
        name
        value
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

Some sample group by's on globalVariables with aggregations for taskDetails and taskLegDetails

anchorRestrictions

1. For any type of query, the query span, i.e. the from and to, should not exceed a period of 12 months.

2. When fetching AAR and CAR raw data, the query span, i.e. from and to cannot exceed more than 30 days.

3. When fetching CSR and CLR documents using pagination, the API supports up to a maximum of 100K records.

4. The number of fields used for a group by operation in an aggregation query cannot exceed 10.

5. When using extFilter in a query to fetch raw data, if matching records for first page cannot be populated from the first 2500 Records (based on query span and filter criteria), then the API will respond back with 413 Status code.

6. The total number of arguments allowed across filters, extFilter and predicates is capped at a default limit of 1000.

anchorRecommendations and best practices

• While querying data or performing aggregations, it is recommended to use fields belonging to only a single data type. Ex: In a taskDetails query, it is recommended to use fields either from CSR or from CAR and not from both. Similarly, for AgentSession query, it is recommended to use fields either from ASR or from AAR.

• It is recommended to use the taskDetails query for any Task related data instead of the older task query.

• For aggregations, use the aggregations argument; the older argument aggregation supports limited functionalities and is not recommended to be used.

• Performing group by's on global variables and skill-related fields is not recommended as the performance may be impacted based on the volume of data.

• Performing group by's on Int, Double or numerical fields or String fields that have a high number of unique values is not recommended.

• It is recommended to pass a TrackingId header with a valid UUID in the request payload, For example - 007bfe3b-a257-4caa-9882-fbd710cc671e;this allows for easier debugging by support teams in case of any issue.

anchorSample Usecases and queries

This repository is organized into multiple files that you can paste directly into the section of the interactive editor on Webex Developer Portal - Search Tasks

anchor| Fetching raw data |

| 13 | [FetchAgentSkill.graphql](https://github.com/WebexSamples/webex-contact-center-api-samples/tree/main/reporting-samples/graphql-sample/More Examples/FetchAgentSkill.graphql) | SKILLS : Extracting Agent skills from an ASR record | Fetching raw data | | 14 | [FilteringUsingAgentSkill.graphql](https://github.com/WebexSamples/webex-contact-center-api-samples/tree/main/reporting-samples/graphql-sample/More Examples/FilteringUsingAgentSkill.graphql) | SKILLS : Filtering ASR records based on Agent skill criteria | Fetching raw data | | 15 | [GroupByAgentSkills.graphql](https://github.com/WebexSamples/webex-contact-center-api-samples/tree/main/reporting-samples/graphql-sample/More Examples/GroupByAgentSkills.graphql) | SKILLS: Group ASR records based on set of skills | Performing Aggregations |

anchorData Dictionary

Refer data dictionaries for available fields and supported operations for each query type and record.

anchorSupport

For dedicated Developer Support on the APIs - Please open a ticket with the team using this link: Webex Contact Center Developer Support

For discussions on the samples, feel free to participate in our Developer Community:

Webex Contact Center APIs Developer Community

Refer: How to Ask a Question or Initiate a Discussion

anchorVersion History

• 0.0.1
  • Initial examples
• 1.0.0
  • Added wallboard-query-samples
• 2.0.0
  • Added several additional example calls
• 3.0.0
  • Update documentation and add more samples.