cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
650
Views
20
Helpful
2
Replies

ApiError for supervisor?

Hi,

I'm trying to perform an API command on an Agent using Supervisor credentials.

Using the AgentRealTime, AgentTeam, and join tables, I find the Agent and the Team Supervisor, then invoke the API against the agent's ID using the Supervisor's login credentials.

I have debugged my joins and it is certain that the supervisor ID is correct for the team to which the agent belongs.  The team has 5 supervisors - I'm not sure I need to be concerned which is the primary supervisor, I just use the Finesse login id of the supervisor performing the action and verify the relationship using the AW tables.

Does the API command have to be performed by the Primary supervisor of a team, or can any of the supervisors perform API commands?

Here is the error I'm getting:

<ApiErrors>
<ApiError>
<ErrorType>User does not belong to Supervisor's Teams</ErrorType>
<ErrorData>20132</ErrorData>
<ErrorMessage>The user does not belong to a Team monitored by the Supervisor specified in the authentication credentials</ErrorMessage>
</ApiError>
</ApiErrors>
 
And there is the URL and body of the command:
https://finesse.company.com/finesse/api/User/20132/Media/5050
<Media><routable>false</routable></Media>
 
When I set the Basic authorization to use the agent's own login, the command works.  When I cycled through the other supervisors, I got a different 401 error (as if authorization did not succeed).
 
Can you suggest something I'm doing wrong here? The only thing that changes between failure and success is the Authorization header between supervisor and agent.. Why, if the AW indicates there's a Team relationship, does the API think there isn't one? 
1 Accepted Solution

Accepted Solutions

Turns out that I was using Agent.SkillTargetID instead of Agent.PeripheralNumber for the {id} portion of the API's URL. Sorry for the bother. A simple query change and it all just works! The reason it worked with different authorization was a fluke - the SkillTargetID matches another agent's PeripheralNumber!

View solution in original post

2 Replies 2

Gerry O'Rourke
Spotlight
Spotlight

I do not know what the issue is - but you will not need to be a Primary Supervisor.

As long as the Supervisor is a supervisor of the team - that should be sufficient to have supervisor access.

 

Gerry

 

Turns out that I was using Agent.SkillTargetID instead of Agent.PeripheralNumber for the {id} portion of the API's URL. Sorry for the bother. A simple query change and it all just works! The reason it worked with different authorization was a fluke - the SkillTargetID matches another agent's PeripheralNumber!