API Command: get_logged_in_reps
The get_logged_in_reps request returns XML data about all logged-in representatives. It requires no additional parameters.
The command API is an authenticated API. For instructions on using authenticated APIs using OAuth, please see Authenticate to the Privileged Remote Access API. The API account must have read-only or full access to the command API.
XML Response for get_logged_in_reps Query
|<logged_in_reps>||Returns a <rep> element for each logged-in representative. If no representatives are logged in, this element will contain no <rep> elements. If an error occurs, it will contain an <error> element describing the problem.|
Element Names and Attributes
|id (attribute)||Unique ID assigned to the representative.|
|<display_name>||This element is deprecated as of API version 1.10.0 but still exists for backwards compatibility. Its value is the same as that of <public_display_name>.|
|<public_display_name>||The public display name currently assigned to the representative.|
|<private_display_name>||The private display name currently assigned to the representative.|
|<type>||The type of rep logged in. Types include Normal and Invited.|
|<direct_link>||An HTML anchor tag containing the URL that customers can use to download the customer client to connect directly to the representative.|
|<logged_in_since>||The date and time at which the representative logged in.|
|<presentation_count>||The number of active presentations the representative is currently running.|
|<support_session_count>||The number of active sessions the representative is currently running.|
|<showing_on_rep_list>||Integer value (1 or 0) indicating if the rep has permission to show on the public site and has the Showing On Representative List option checked in the access console.|
Query Example: get_logged_in_reps
If you experience a high volume of support requests, repeatedly calling a command such as get_logged_in_reps might bottleneck your system. Therefore, a best practice is to not request a list of representatives or teams with each support request. Instead, if making the same API call in succession, consider caching the results for a period of time and reusing them. New sessions requests should reference the cached list instead of calling for the list each time.