I am using conversationAPI.PostConversationsChatParticipantReplaceAsync method which the documentation states (SDK Doc) requires only permission conversation:communication:blindTransfer
But I get an error back: 403 Forbidden. The rest of the error does not explicitly name a missing permission.
I am using the method to transfer the participant as an unattended transfer to a userId.
I follow that with a PatchConversationsChatAsync to then disconnect the call, which the SDK states only needs permission conversation:communication:disconnect
My Role has these permissions.
I assume there is a missing permission from the documentation as adding the whole permission "conversation > All permissions" works.
The SDK doc marries up with the API explorer permissions listed for the underlying API endpoints called from these methods.
Can you advise on method permissions so I can lock the role down to the least privilege permissions needed for the integration?
I would also like to ask, save another post, and as related to the integration...
why does the method PostConversationsChatAsync Attributes parameter appear to add a prefix context. to the participant attribute name I provide when the interaction is created?
I pass a dictionary<string,string> Attributes with single entry;
Attributes.Add("Reference", model.Reference)
but the attribute in the interaction view (and API explorer) has context.Reference
There are two bugs here that can only be handled by opening a case with Care:
the resource is enforcing a permission that it has failed to document
the resource is failing to return an appropriate error that indicates what permission is missing
For you're last question:
why does the method PostConversationsChatAsync Attributes parameter appear to add a prefix context. to the participant attribute name I provide when the interaction is created?
I'm currently reaching out to the appropriate team but from what information I have so far, this is intended behavior.
I created a support case yesterday as had not heard anything back here. With ServOps now apparently.
As for the erroneous prefix. It is not documented as doing this and find it strange that this would be arbitrary added without a reason I can determine. Anywhere else I add a participant key/value pair yields the Key I provide, not a key with a context. prefix ?
Dev has stated working as designed, I feel like a lazy answer provided without an explanation nor documentation. I would expect the key to be the value I provide.