The command API is designed to send commands to your Bomgar site from an outside application. Commands can start or transfer a support session, get a list of logged-in representatives, or obtain a list of support teams and issues. You can also check the health of your appliance, change an appliance's failover role, or get information about your Bomgar API version.
The command API is an authenticated API. For instructions on using authenticated APIs using OAuth, see Authenticate to the Remote Support API.
Commands are executed by sending an HTTP request to the appliance. Send the request using any HTTPS-capable socket library or scripting language module, web browser, or URL fetcher such as cURL or wget. Use either GET or POST as the request method.
When making consecutive API calls, you must close the connection after each API call.
The command API URL is https://support.example.com/api/command.
An XML schema describing the command API response format is available at https://support.example.com/api/command.xsd.
The type of action to perform. Can be any of the following:
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.
The command API returns XML responses that declare a namespace. If you are parsing these responses with a namespace-aware parser, you need to set the namespace appropriately or ignore the namespace while parsing the XML.
- Command API: https://www.bomgar.com/namespaces/API/command
Note: The above namespace is returned XML data and is not a functional URL.
Note: Prior to 16.2, a user account was used to authenticate to the API, with the username and password being passed in the request. Starting with 16.2, this method has been deprecated and is not available to new users. Instead, one or more API accounts must be created, with their client IDs and client secrets used to generate OAuth tokens. The only API which still requires a user account is the real-time state API.
For users upgrading from a version prior to 16.2, the option to authenticate to the API with a user account is still available for backwards compatibility. However, it is highly recommended that you use the more secure OAuth method of authentication. If you are unable to switch to OAuth authentication, please follow the API request format described in our documentation archive.