Create API endpoint to get list of interviewers and attributes on them

There is an endpoint that returns the list of supervisors (GET /api/v1/supervisors), but there is no endpoint for obtaining the list of interviewers and some basic attributes about them. The only way to get a list of interviewers is to pass through the supervisor (GET /api/v1/supervisors/{supervisorId}/interviewers).

Consider providing API users with direct access. The API endpoints provide an interface for GUI actions. The GUI provides a list of interviewers (Teams and Roles > Interviewers). The API should, then, have an interface for this action.

Consider providing the same information via this endpoint as is present in the GUI (e.g., interviewer login name, supervisor login name, etc.)

See this these threads for some potential use cases for this new endpoint: here and here.


Hi @arthurshaw2002, has this endpoint been provided?

For the REST API, no. The situation is still the same. Of course, one can write a wrapper function that orchestrates the two calls: first, to the supervisor endpoint; then, to the interviewer endpoint. (See, for example, susoapi::get_interviewers())

For the GraphQL API, the development team could say better. For my part, it’s on my to-do list to investigate. But my quick reading is that GraphQL provides a list of users of all types, but does not provide the relationships (e.g., Interviewer123 is a an interviewer, but it’s unclear who the supervisor is)

@zurab, @sergiy , is there currently any way to use the GraphQL API to get, for a given workspace:

  • List of interviewers for a given supervisor
  • List of supervisors and interviewers and which interviewer is works for which supervisor


Maybe I’m missing something, but I do not see a way with GraphQL. First, there is no node that provides the interviewer’s supervisor or, more generically, a user’s superior user(s). Second, there is no filter that would allow one to fetch interviewers for a supervisor with, say, a given ID.

/api/v1/supervisors/{supervisorId}/interviewers - list of interviewers for given supervisor. There is no similar filter available in GraphQL API endpoint at this moment.

If you need information on any specific user, you can just call the appropriate endpoint with user_id, but
if your goal to create a complete copy of the users list with their properties? then just get /api/v1/supervisors the list of all supervisors and loop through them to get all their interviewers.

Many thanks, @zurab, for confirming that GraphQL cannot do this currently and explaining how to do this with the REST API.

If it’s not an abuse of this thread–I can create another if preferred–I’d like to update my feature request: change GraphQL API endpoint to allow users to obtain a list of interviewers and their interviewers.

I see a few complementary ways this might be implemented:

  1. Add a supervisor field (or superior user field). In this way, one could request a list of all users. For interviewers, one could see the supervisor (e.g., single string value with name or ID, both fields, etc.). For supervisors, the returned value would depend on the implementation choice. If one chooses to have a supervisor field, the returned value of this field should be null. If one elects to have a superior user field, the returned value should be a list of headquarters users.
  2. Add a supervisor filter. In this way, if desired, one could request the interviewers for a particular supervisor.

Another implementation consideration: whether to require a workspace or not. If a workspace is required, the return values could be relatively flat–that is, the values for the requested workspace only. If a workspace is an optional filter, then the return values, in some cases, would need to be indexed by workspace (e.g., a list of supervisors by workspace for a given interviewer).

Separately, the GraphQL API is missing one field relative to REST: DeviceId. Not sure if anyone uses this field. Not sure that I’ve ever used it. But I did want to point this out, since I understand that GraphQL often has “feature parity” with REST where there’s functional overlap between the two API systems.

I think that the developer(s) using API to implement a specific task should not ‘worry’ too much whether the same action can be performed in multiple ways, i.e. using rest call or a graphql one. One thing is to not have ability to perform specific action altogether, but just ‘beautifying’ an API, which, I’d love to have as well, has much less of an urgency, given (as always) competing priorities and limited resources.

You may already know my opinion that I’d rather have all these implementation details be ‘hidden’ by the API clients for specific languages (and yes, those few of us working on writing these clients will deal with rest vs graphql question) so that the rest of the developer/user community doesn’t need to be bothered with the question of what ‘syntax’ is used for any particular web request.