i’m just noticing the participant attributes are wiping out mid-call right after the patch hits /api/v2/conversations/{conversationId}/participants/{participantId}. it’s returning a 422 with zero useful context in the body.
- cxone studio snippet using GetRESTProxy
- headers set to application/json
- body:
{"attributes": {"routing_priority": 99, "custom_tag": "escalated"}}
- already verified the bearer token is valid for other endpoints
don’t know if the studio proxy is stripping the nested object or if the conversations api expects a flattened structure.
422 usually means the payload schema is off. The Conversations API doesn’t accept a raw attributes object in that PATCH body. You need to wrap it in a attributes field inside the participant update structure, or just hit the dedicated /attributes endpoint. Try:
{
"attributes": {
"routing_priority": 99,
"custom_tag": "escalated"
}
}
Wait, that’s what you sent. The issue is likely the routing_priority key. That’s a reserved field. Custom attributes must be under custom or use the specific attribute endpoint. Check the schema validator.
the 422 is likely coming from the schema mismatch on the participant object itself, not just the attributes. the body needs to match the Participant model, not just a raw json object.
in nice cxone, you can often just pass the attributes directly and it figures it out. genesys is stricter. try wrapping it like this:
{
"attributes": {
"routing_priority": 99,
"custom_tag": "escalated"
},
"wrapUpCode": null
}
sometimes leaving out required fields or sending nulls for optional ones triggers the validation error in the patch handler. if that fails, check the api docs for the specific participant update schema. it’s easy to miss a nested requirement.
You’re hitting the strict schema validation on the PATCH body. Wrap your attributes in the correct object structure and explicitly set wrapUpCode to null to satisfy the model.
{
"attributes": {
"routing_priority": 99,
"custom_tag": "escalated"
},
"wrapUpCode": null
}