403 Forbidden Error when Accepting transferred call

Platform API Java SDK
1

I get a error when I try to accept a call which has been transferred.

I can accept an incoming call without a problem but if I accept the call and then transfer to another queue I am unable to accept it (on the new queue) as it keeps coming back with Error 403 below.

Any ideas on what could be wrong?

{"status":403,"code":"conversations.error.forbidden","message":"Access to Conversation 06e1d2e3-ec2d-4e76-9abb-96809677f159 is forbidden.","messageWithParams":"Access to {type} {id} is forbidden.","messageParams":{"id":"06e1d2e3-ec2d-4e76-9abb-96809677f159","type":"Conversation"},"contextId":"0d707943-1d46-4718-a740-94eb46b6719b","details":[],"errors":[]}

2

@tim.smith any idea on this one?

3

The request is being made as user b363d583-9a20-44ee-bc13-d70194486fca, but that user is trying to answer the interaction for a participant on behalf of a different user. Participant feb2fa3f-23fb-4375-a995-f3049b544dc6 is for agent 86e16938-065c-4579-a2bb-d732825e2195. So it looks like you're making the request with the wrong session (I'm guessing your application is a multi-tennant middleware). Does that help?

4

So you mean, I am making the request using the wrong participantId?

Also, not sure what do u mean by wrong session? The conversation is the same one. Agent1 b363d583-9a20-44ee-bc13-d70194486fca answered it first on Queue 1 and then transfered it back to another queue (Queue 2) and then agent 2 86e16938-065c-4579-a2bb-d732825e2195 got an alert. When I got the error, I was trying to get Agent 2 86e16938-065c-4579-a2bb-d732825e2195 to answer it.

Still unsure how I can fix this? Any suggestions?

5

Your request:

PATCH api/v2/conversations/06e1d2e3-ec2d-4e76-9abb-96809677f159/participants/feb2fa3f-23fb-4375-a995-f3049b544dc6

was made to act on participant feb2fa3f-23fb-4375-a995-f3049b544dc6, which is for user ID 86e16938-065c-4579-a2bb-d732825e2195. However, the request was made by user id b363d583-9a20-44ee-bc13-d70194486fca which is the user for participant e2422f0d-5995-4fc3-8a4d-e1122d941187.

So you tried to answer a participant with the wrong user. When trying to determine which participant is your user's, be sure all of the following are true:

  1. Participant's userId matches your session's user ID.
  2. The participant is not disconnected (endTime is not set)

edit: given your explanation that...

  • Agent1 = b363d583-9a20-44ee-bc13-d70194486fca
  • Agent2 = 86e16938-065c-4579-a2bb-d732825e2195

You used Agent1's auth token when making the request to answer the call for Agent2. This is why I said it looks like you're using the wrong session.

1 Like
7

Yes, it looks like wrong token (session) may be getting used. However, is this restriction only on conversation (calls etc)?

I think changing a user presence still works even if you pass a wrong token (i.e. Agent1's token can be passed when changing Agent2's presence) . Can you confirm this is the case?

8

You're going to see lots of unexpected behavior if you're using incorrect sessions to make API requests. Every resource that requires a user will behave unexpectedly. Every resource that has audit logging will be impacted because you'll be generating incorrect data. Every request has a user context passed with it, so all of the logging will be incorrect. This is something that should absolutely be avoided.

1 Like
9