Setting wrap-up codes via Conversations API after interaction end

NICE CXone API & Integrations
1

We are automating our post-interaction workflows using the Genesys Cloud Conversations API. The requirement is to programmatically assign a specific wrap-up code once an interaction has transitioned to the ended state.

We are currently attempting a PATCH request to /api/v2/conversations/{conversationId}. The payload includes the wrapupCode object with the correct code ID retrieved from our provisioning scripts. However, the API returns a 409 Conflict status with the message “Cannot update wrapup code for ended conversation”.

Here is the JSON body we are sending:

{
 "wrapupCode": {
 "id": "c9a8b7d6-5e4f-3a2b-1c0d-9e8f7a6b5c4d",
 "name": "System Update"
 }
}

The documentation states that wrap-up codes can be set during the wrapup phase, but our automated process triggers after the agent has already clicked end. We have tried using the wrapupCodeId field at the top level instead of the object, which results in a 400 Bad Request indicating an invalid field.

Is there a specific endpoint or parameter we are missing to force this update on a closed interaction? We need this to sync with our external CRM before the record is archived.

2

Wrap-up codes are immutable post-interaction. You can’t patch them via the Conversations API. If you need dynamic assignment, use the setWrapup action in a Studio script or Architect flow before the interaction ends.

3

That’s the right path. The wrapupCode object in the PATCH payload needs the id and reason fields. If you’re getting a 400, check that the code ID matches a code in the queue’s wrap-up configuration. Also, ensure the conversation is actually in the ended state before sending the request. Here’s the payload structure:

{
 "wrapupCode": {
 "id": "your-wrap-up-code-id",
 "reason": "Customer issue resolved"
 }
}

Make sure your-wrap-up-code-id is the actual ID from the /api/v2/routing/wrapupcodes endpoint. If the code isn’t assigned to the queue, it’ll fail. This worked for our automated post-call tasks.

4

You’re probably hitting a timing issue or a scope mismatch with the queue configuration. The Conversations API is strict about the state. If you try to patch the wrapupCode before the conversation is fully ended, it’ll reject it. Also, make sure the wrap-up code ID you’re using actually belongs to the queue associated with that conversation. You can’t just pick any code from your org.

Here’s how I handle this in Terraform to ensure the IDs are correct and the state is respected. First, grab the queue and the wrap-up code ID from the provider so you aren’t hardcoding magic strings.

data "genesyscloud_routing_queue" "support_queue" {
 name = "Support Queue"
}

data "genesyscloud_routing_wrapupcode" "resolved_code" {
 name = "Resolved"
 domain_id = data.genesyscloud_routing_queue.support_queue.id
}

Then, in your automation script (Node.js example using platform-client), wait for the state change event before firing the PATCH. Don’t just loop blindly.

const conversationId = 'your-conversation-id';
const wrapupCodeId = 'your-wrapup-code-id'; // Use the ID from Terraform output

// Wait for 'ended' state via WebSocket or polling
const response = await platformClient.ConversationsApi.patchConversation(
 conversationId,
 {
 wrapupCode: {
 id: wrapupCodeId
 }
 }
);

If you get a 400, check the reason field in the error. It usually tells you if the code isn’t valid for that queue. Also, verify your OAuth token has conversation:write scope. Missing scopes are a common culprit when things seem right but fail silently or with generic errors.