Then i use
GET /api/v2/conversations/calls/{conversationId}
again but the priority remains unchanged. ("priority": 0)
Why didn't Priority update, i thought that was the point of that API?
I feel like the answer is, it doesn't work that way. And that is fine, but it seems like it should work that way?
End result I'm looking for is to have a couple of DataActions run in an Agent script to Initate a consult to a Queue and set the priority, bypassing the need to consult to an internal number to go to a flow to set the priority there instead.
hi Anton. you're not doing anything wrong; this is a known issue. the ability to update attributes of in-queue conversations is still new, and all the wires haven't been connected yet w.r.t. informing the entire platform of the changes to the in-queue conversation. your source of truth here is the response from the initial PATCH request. that should show the updated priority. you can also submit subsequent PATCH requests with empty-JSON request bodies (i.e. just {}) to see the current state of the modifiable fields. hope that helps.
Hijacking this a little, but if we're monitoring the Queues via a websocket (v2.routing.queues.{QueueId}.conversations) would the Priority there reflect these changes or would that also be subject to the known issue of not having been informed of the changes?
Is that known limit documented somewhere in more detail so we can check assumptions against it?
Eos, the priority change will not be reflected in that notification stream.
and sorry, but we don't have these limitations documented anywhere. we're hoping to just fix the situation soon, but don't have a concrete timeline on that yet.