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 representative 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 currently has permission to show on the public site and has their Showing On Representative List preference checked in the rep console.

Query Example: get_logged_in_reps



IMPORTANT! If you are experiencing a high volume of support requests, repeatedly calling a command such as get_logged_in_reps or get_support_teams can potentially bottleneck your system. Therefore, a best practice is not to request a list of representatives or teams with each support request. Instead, if you are making the same API call in succession, consider caching the results for a period of time and reusing them. New sessions requests should reference this cached list instead of calling for the list each time.