So, we’re mapping wrap-up codes from CXone to Genesys Cloud - obviously, CXone just dumps everything into a single table, but GC’s bit more granular with the routing object. I’m trying to pull the wrap-up codes via the Routing API, specifically looking for something equivalent to the CXone get_routing_wrapupcodes call, but it doesn’t seem to exist.
The documentation only shows endpoints for retrieving queues, skills, and agents, but nothing that lists the available wrap-up codes for a given skill or queue. We’re on GC Platform API v6.2.0, and the Python SDK is 6.1.0. Is there a different endpoint I’m missing, or am I expected to scrape this data from the UI or build a lookup table manually?
It’s weird because you can set wrap-up codes within Architect flows, but there’s no API to list what’s already configured. I’ve tried hitting /routing/v6.2.0/wrapupcodes and /routing/v6.2.0/skills/{skillId}/wrapupcodes with no luck - both just return 404. Anyone else run into this?
The absence of a dedicated endpoint for wrap-up code retrieval via the Routing API is a noted deficiency. We’ve encountered similar limitations when migrating contact centers and establishing a documented system of record.
The current architecture necessitates a composite approach. The Genesys Cloud documentation details the retrieval of routing configurations - queues, skills, and agents - as you’ve observed. However, wrap-up codes are embedded within the queue definitions.
To extract this data programmatically, you’ll need to iterate through each queue and parse the associated wrap-up codes from the queue’s JSON representation. Consider the following example using GET /api/v2/routing/queues:
GET /api/v2/routing/queues?expand=wrapupCodes
This request will include the wrap-up code details in the response body. You’ll then need to parse the JSON to extract the specific codes and their associated metadata. This approach, while functional, introduces a dependency on the queue structure.
It’s imperative to establish a data validation process to confirm the integrity of the extracted wrap-up codes. Any discrepancies between the source system (CXone) and Genesys Cloud could create a compliance risk. I suggest incorporating automated tests to verify data consistency. A previous thread discussing data mapping challenges - I believe it was related to data actions - highlighted the importance of schema validation. We’ve found it beneficial to create a baseline of expected wrap-up codes and flag any deviations.
Thanks so much - that makes a lot of sense, actually.
It’s kinda weird they’d bury wrap-ups in the queue objects, but I guess that’s how it is - makes me wonder about state drift if queues change independently, but we’re on Genesys Cloud so hopefully that’s less of a thing.
I was looking at the /api/v2/routing/queues endpoint, and yeah, the wrapupCodes array is right there in the response - I was expecting something separate, like a dedicated list, so I totally missed it.
Here’s how you’d pull it with Terraform, just in case anyone else runs into this.
You’ll need to loop through all your queues and extract them - it’s not ideal, but it works.
data "genesyscloud_routing_queue" "queues" {
name = ".*" # Or a more specific filter
}
locals {
all_wrapup_codes = []
}
resource "null_resource" "extract_wrapup_codes" {
triggers = {
queue_data = data.genesyscloud_routing_queue.queues.id
}
provisioner "local-exec" {
command = <<EOF
echo '${jsonencode(data.genesyscloud_routing_queue.queues.wrapup_codes)}' >> wrapup_codes.json
EOF
}
}
The data block gets all the queues - you’ll want to refine that name filter.
Then, the null_resource is a bit of a hack, but it forces a re-run when the queue data changes, and it dumps the wrapup codes to a json file.
You’d probably want to do something smarter with the output - maybe flatten it into a map or list for easier use.
It feels kinda kludgy, but it’ll let you get a list of all available codes. I’m still learning the best way to handle this stuff, so I’m happy to hear if anyone has a better approach.
Oh nice, glad it worked out! Yeah, I totally should’ve checked the queue objects first - we do everything in queues in CXone, so I was kinda assuming GC would separate it out. State drift is a concern, good call on that - we’ve got change management processes in place for queue updates, so hopefully that’ll catch anything.
Okay, so you’re mapping wrap-up codes - that’s a really common snag when migrating from one platform to another. It’s like trying to navigate a new city - you expect the landmarks to be in familiar places, and when they aren’t, it throws you off. You’re right to focus on that CXone to Genesys Cloud transition; it’s where most people hit this particular wall.
Don’t beat yourself up about missing the wrap-up codes inside the queue objects - it’s a bit counterintuitive. It took my team a while to adjust to that, too. the earlier post’s suggestion is absolutely spot on, though. Genesys Cloud does embed those within the queue definitions.
I think it’s worth highlighting the official documentation on queue retrieval - it’s surprisingly clear once you know where to look. From the Genesys Cloud Resource Guide - Routing Queues, it states that the queue object includes a wrapupCodes array. It’s not a separate endpoint, unfortunately.
Here’s a quick example of how you’d extract those codes using curl:
curl -X GET "https://api.genesyscloud.com/api/v2/routing/queues/{queueId}" \
-H "Authorization: Bearer {your_auth_token}"
The JSON response will contain something like this:
Just remember that, as As noted above, that queue object is the source of truth for these wrap-up codes. State drift is a valid concern, and you’re smart to have change management in place for queue updates. That’s crucial. It’s a bit like updating a city map - if one street changes, you have to update the whole map to keep it accurate.