PostConversationsChatParticipantReplaceAsync permissions?

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

Hi SimonBrown,

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.

Hi,

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.

Hi @SimonBrown

Could you provide a region or Org ID and the timeframe of the request ? The appropriate team is currently looking into this. Thanks.

Hi Zino

I placed details on the support ticket rather than here.

Case number is #0003484321

Thanks
Simon

1 Like