How to Adjust Conversation Priority in Genesys Cloud Using the /api/v2/routing/conversations Patch Endpoint
What This Guide Covers
This guide details how to dynamically adjust the priority of an in-flight conversation in Genesys Cloud CX using the REST API. This allows for real-time intervention to elevate critical interactions, for example, to ensure a VIP caller is quickly connected to a skilled agent, or to expedite handling of time-sensitive issues. The end result is a conversation whose priority has been modified mid-interaction, impacting its position in agent work queues.
Prerequisites, Roles & Licensing
This functionality requires Genesys Cloud CX Professional or higher licensing. The user account performing the API call requires the following permissions:
Routing > Conversation > ViewRouting > Conversation > Edit- Specifically, the permission string
routing.conversations.patchis crucial.
The OAuth scope needed is routing. This functionality assumes a pre-existing, active conversation. External dependencies include a system capable of making authenticated REST API calls to the Genesys Cloud CX environment.
The Implementation Deep-Dive
1. Identifying the Conversation ID
Before modifying priority, the unique Conversation ID must be obtained. This can be done via several methods: a user interacting with the contact center initiates the conversation, triggering a webhook to your system, or through a manual query of active conversations via the API. The most reliable method is to capture the conversation ID when the interaction begins, storing it in your external system for later use.
The API endpoint to list active conversations is:
GET /api/v2/routing/conversations
This endpoint requires pagination if there are a large number of active conversations. The pageSize and pageNumber query parameters can be used to iterate through results. The conversationId will be the key identifier.
2. Constructing the PATCH Request Payload
The core of this process is the PATCH request to the /api/v2/routing/conversations/{conversationId} endpoint. The payload is a JSON object defining the desired priority value.
{
"priority": 1
}
The priority field accepts integer values. Lower numbers indicate higher priority. Genesys Cloud CX defines priority levels as follows:
- 0: Highest Priority
- 1: High Priority
- 2: Normal Priority (default)
- 3: Low Priority
- 4: Lowest Priority
The Trap: A frequent misconfiguration is setting the priority to a value higher than 0, mistakenly believing that a larger number equates to higher importance. This will demote the conversation, potentially burying it in the queue. Always remember lower numbers are higher priority.
3. Executing the PATCH Request
The PATCH request is made to the following endpoint:
PATCH /api/v2/routing/conversations/{conversationId}
Content-Type: application/json
Authorization: Bearer {OAuth Token}
Example using curl:
curl -X PATCH \
'https://api.genesyscloud.com/v2/routing/conversations/YOUR_CONVERSATION_ID' \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer YOUR_OAUTH_TOKEN' \
-d '{
"priority": 0
}'
The response will be a 200 OK status code if successful. The body of the response will contain the updated conversation object.
The architectural reasoning for using PATCH instead of PUT is that PATCH allows for partial updates. We are only modifying the priority field, leaving other conversation attributes untouched. This minimizes potential side effects and improves performance. PUT would require providing the entire conversation object, even unchanged fields.
4. Considerations for Queue Assignment Logic
Changing the priority of a conversation doesn’t automatically move the conversation to a higher priority position. It impacts the next evaluation cycle of the queue assignment logic. The system re-evaluates queue assignments based on the updated priority. Therefore, the impact of the priority change may not be immediately visible.
Furthermore, queue assignment logic is complex and considers factors beyond priority, such as agent skill sets, availability, and wrap-up time. Adjusting the priority is a signal to the system, not a guarantee of immediate escalation.
Validation, Edge Cases & Troubleshooting
Edge Case 1: Invalid Conversation ID
- The failure condition: Attempting to PATCH a non-existent conversation ID results in a 404 Not Found error.
- The root cause: The provided
conversationIddoes not correspond to an active conversation in the Genesys Cloud CX instance. - The solution: Verify the
conversationIdis valid and the conversation is still active. Check logs for potential errors in the ID capture or storage process.
Edge Case 2: Insufficient Permissions
- The failure condition: A 403 Forbidden error is returned.
- The root cause: The user account performing the API call lacks the necessary
routing.conversations.patchpermission. - The solution: Assign the required permission to the user role. Verify that the OAuth token used in the request is associated with a user possessing the necessary privileges.
Edge Case 3: Rate Limiting
- The failure condition: A 429 Too Many Requests error is returned.
- The root cause: The application has exceeded the API rate limits. Genesys Cloud CX imposes rate limits to prevent abuse and maintain system stability.
- The solution: Implement exponential backoff with retry logic in your application. Monitor API usage and adjust the request rate accordingly. Refer to the Genesys Cloud CX Developer Center for current rate limit details.
Edge Case 4: Conversation Already Resolved
- The failure condition: While the API call may succeed with a 200 OK response, the priority change has no effect.
- The root cause: The conversation has already been resolved (completed, abandoned, etc.) after the conversation ID was retrieved but before the PATCH request was executed.
- The solution: Implement checks to ensure the conversation is still in an active state before attempting to modify its priority.