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.
In order to issue the get_logged_in_reps command, you will need to supply the username and password for a Bomgar user account. That account must have the permission Allowed to Use 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, Embassy 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 rep console.|
Query Example: get_logged_in_reps
IMPORTANT! If you experience a high volume of support requests, repeatedly calling a command such as get_logged_in_reps or get_support_teams might bottleneck your system. Therefore, a best practice is not to 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.