Routing Status, Skills, and Language Missing in Routing API Call

When I make the following API call with the Routing API, /api/v2/routing/queues/queueID/members
It returns the list of members, but the Routing status and Skills parameters are missing in the response. If I try to filter on IDLE routing status, the response is empty. I want to find number of members onqueue with a particular language and skill mapping.

How do I view the list of valid routing statuses?

Issue has been resolved, but why does the information not show up without querying for a specific parameter? For example, if I run the query with no filters, it doesn't return the language, skill, presence, or routing status of the members.

Hi Jared,

There are a couple of ways to answer the question. If you are going to use the APIs then you need to first get a list of all of the members of the queues via the GET /api/v2/routing/queues/queueID/members call. Then you need to iterate through each member and call either the GET /api/v2/users/{userId} endpoint with the --expand values set include routingStatus and skills. The expands HTTP parameter will retrieve the user information and then also automatically call the GET /api/v2/users/{userId}/routingstatus and the GET /api/v2/users/{userId}/routingskills endpoints under the covers.

Genesys Cloud stores these mappings in different tables and has different API endpoints to manage them. Since we use a non-relational database, these types of joins have to be done via multiple API calls.

The reason why I say it depends on my opening remarks is that the scenario you are describing with your original question, indicates you want to have almost an event-driven near-time processing as the user's status changes. While you could poll with the above endpoints, depending on the number of users and queues you are trying to process you can quickly run into our rate limits for API calls (300 API calls per minute per Oauth client).

In an event-based processing model, you are better off using our notification service or our AWS Event Bridge (which is in Beta but soon to be GAed). The notification service allows you to open a websocket and listen for events from Genesys Cloud as they happen. The AWS Event bridge sends the events over an AWS Event Bridge and to some target (e.g. a Lambda).

Here are some docs for you to look at:

  1. Notification Service
  2. AWS Event Bridge
  3. Available topics to subscribe to

We also have some videos on the notification services under our DevDrops section for videos. We have a couple of recent videos with examples in Python and using our CLI and the notification service.

I would also recommend you play around with our notification testing tool as it allows you to subscribe to Genesys Cloud events to get a feel for the data that comes back from them.

I hope that helps.

Thanks,
John Carnell
Manager, Developer Engagement

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.