APIs | Sisense Community

Automating Dashboard Ownership Transfer in Sisense with UserReplaceTool Managing and deleting user accounts in Sisense can create manual processes when users leave an organization or change roles. A frequent issue is the reassignment of dashboard ownership to prevent losing Sisense dashboards when a given user account is deleted, as deleting a Sisense user will delete all dashboards owned by that user. The UserReplaceTool addresses this task by automating the transfer of dashboard ownership of all dashboards owned by a given user, ensuring continuity and data integrity. Overview UserReplaceTool is a Python-based, API-based Tool solution designed to seamlessly transfer the ownership of dashboards and data models from one user to another in Sisense. This tool simplifies and automates this process, allowing organizations to reassign dashboard ownership without manual processes or the risk of losing dashboards and widgets. All components are accomplished by using Sisense API endpoint requests. Key Features Automated Dashboard Transfer : Reassigns ownership of all dashboards from the current user to a designated replacement user. Data Model Sharing : Ensures that all data models accessible and editable by the previous user are shared with the replacement user. Batch User Processing : Capable of handling multiple user transfers to a replacement user in a single operation, enhancing efficiency. Complete Logging: All dashboards and datasource transferred are logged both in the console and in a separate log file. Setup Instructions 1. Setting Up the Environment To run the tool within a Python virtual environment , follow these steps: Activate the Python Virtual Environment : source /venv/bin/activate Create a Virtual Environment (if not already present): python3 -m venv .venv Install Dependencies : pip3 install -r requirements.txt For manual installation, including without using a Python virtual environment: pip3 install urllib3 jsonpath_ng pyyaml requests colorama 2. Configuration Edit the settings.yaml file to configure the tool. Key parameters include: Sisense Domain and Port : Specify the URL and port of your Sisense server, which is used for making API requests. API Bearer Token : Provide an admin-level bearer token for API authentication. See the Sisense API Bearer Token Documentation for instructions on generating and using Bearer Tokens. Users to Replace : List the user IDs to be replaced. User IDs can be retrieved via the Users API or using the console command prism .user._id. Replacement User : Specify the user ID of the new replacement owner of all dashboards. This should typically be an admin level user. Data Model Sharing : Enable or disable the sharing of data models with the Replacement user (True or False), usually True. Dashboard Ownership Transfer : Enable or disable the transfer of dashboard ownership (True or False), usually True. Unlike Dashboards, if a user is deleted, the datasources themselves are not deleted from the server, ownership is automatically transferred to the main System Admin of the Sisense server. 3. Running the Tool Run the tool with the following command: python3 replaceUser.py Practical Considerations Admin and Network Access : Ensure you have admin-level API access to the Sisense instance. Python Environment : Python3 and pip should be installed on the machine running the tool. All dependencies can be installed using Pip, and a Python virtual environment can be used. Once a Python Virtual Environment folder is set up it can be shared with the Tool and run directly on all systems using the same OS, but it is not cross OS compatible. By automating the transfer of dashboard ownership, UserReplaceTool provides a reliable and efficient solution for managing user transitions in Sisense. This ensures that datasources and dashboards remain accessible and under the control of the appropriate users, maintaining the continuity of Sisense resources. For further customization and configuration details, refer to the attached full Python Tool, which includes a README file and modify the "settings.yaml" file as necessary.

APIs

Manually Revoking a Sisense Bearer Token

Manually Revoking a Sisense Bearer Token On newer versions of Sisense, bearer tokens expire automatically by default after a time period set by the system administrator. For most use cases, allowing a token to expire automatically, or rotating it as part of standard security practice, is sufficient. This article covers how to revoke a bearer token immediately, for cases where automatic expiration is not sufficient for the use case. Consult the Security Bearer Tokens documentation for information about bearer token expiration, renewal, and the default behavior on new and upgraded instances. For other authentication endpoints not related to revocation, see the REST API v1.0 Reference . The examples below use curl to show each API call plainly, with the method, URL, and headers all visible in one place. The same calls can be made with equivalent code in JavaScript, Python, or any other language capable of making an HTTP request. Curl is used as a convenient way to display the endpoint being called. Understand bearer token scope A bearer token grants access to the Sisense REST API on behalf of the user identified by the credentials used to generate it (username and password, SSO, cookie, or a previous bearer token). The token does not elevate the user's permissions beyond what they already have: If the user is deleted, the token becomes invalid automatically. If the user only has Viewer role access, API calls made with the token are limited to Viewer role API endpoints. Data security rules, data source access permissions, dashboard sharing settings (which users and groups a dashboard or data source is shared with), and saved filters configured for the user in the native Sisense application all still apply to API calls made with the token. Using a token does not grant access to anything the user could not already see by logging in through the web UI. The token is functionally equivalent to the user logging in through the Sisense UI in terms of what is accessible. Two types of bearer tokens Sisense has two distinct variants of bearer tokens with slight differences in revocation behavior. Bearer tokens generated through the token generation API endpoint (the variant the DELETE endpoint in the next section can be used for admin tokens). The personal token, found on the Profile token page ( /app/profile/apitoken ) and available only if User Profile > API Token is enabled in Feature Management. It is also a bearer token, authenticated the same way with an Authorization: Bearer header in API calls. The DELETE endpoint in the next section only revokes admin tokens generated through the token generation API. It does not apply to personal tokens, and it requires admin privileges. The renew endpoint below is not limited that way. It works for both token types, requires no admin privileges, and is documented in API Bearer Token Lifecycle in Sisense (Linux) . Calling it with any valid bearer token, personal or otherwise, invalidates every bearer token currently issued to that token's user and returns one new token. Unlike the DELETE endpoint, it only ever acts on the user identified by the token used to call it. It cannot be used to revoke another user's tokens. On the User Profile > API Token page, this same action is triggered by the Refresh button. For a user without admin privileges, renew is the only available option. No self-service endpoint revokes a token without also issuing a replacement; only the admin DELETE endpoint can revoke a token outright with no new token generated. In practice, calling renew and then never using or saving the newly issued token comes close to the same result: the previous token is invalidated immediately, and if the new token is discarded, no valid token remains in active use. If personal tokens are not enabled in Feature Management, the DELETE endpoint can be used for every token that exists on the server, since none of them will be personal tokens. curl -X POST "https://$SISENSE_URL/api/v1/authentication/tokens/api/renew" \ -H "Authorization: Bearer $TOKEN_TO_ROTATE" \ -H "Accept: application/json" The response contains the new token: { "token": "$NEW_TOKEN" } Every bearer token previously issued to this user, including the one used to authenticate this request, is invalidated immediately. Only the newly issued token remains valid. Get the user ID to revoke a token Revoking (and not renewing) a token requires the Sisense user ID of the token's owner. Retrieve it in one of the following ways. The most direct method is to query the API using the token itself. The response is the profile of the token's owner, including their user ID in the _id field: curl -X GET "https://$SISENSE_URL/api/users/loggedin" \ -H "Authorization: Bearer $TOKEN_TO_REVOKE" \ -H "Accept: application/json" If the token belongs to the currently logged in user, the ID can also be retrieved from the browser developer console without an API call: prism.user._id Alternatively, the user ID can be extracted directly from the token's payload with JavaScript, without calling the API: function extractUserIdFromToken(token) { try { const parts = token.split('.'); if (parts.length !== 3) { console.error('Invalid token format'); return null; } // Base64 decode the payload (second part) const payload = parts[1]; const decoded = JSON.parse( atob(payload.replace(/-/g, '+').replace(/_/g, '/')) ); return decoded.user; } catch (error) { console.error('Error decoding token:', error); return null; } } // Extract the user ID from your token const userId = extractUserIdFromToken('$TOKEN_TO_REVOKE'); console.log('User ID:', userId); The same decoding can be done in Python or any other standard programming language. Revoke a bearer token To revoke a bearer token before its automatic expiration time, send a DELETE request to the authentication admin tokens endpoint : curl -X DELETE "https://$SISENSE_URL/api/v1/authentication/admin/tokens/api?users=$USER_ID" \ -H "Authorization: Bearer $ADMIN_TOKEN" \ -H "Accept: application/json" Replace the following: $SISENSE_URL with the organization's Sisense URL (for example, mysisense.com ) $USER_ID with the Sisense user id (obtained using one of the methods in the previous section) $ADMIN_TOKEN with a valid bearer token that has admin privileges The API returns HTTP 204 No Content on success. This status indicates the request was processed, but does not confirm that the token was valid before revocation. Confirm the token is revoked A 204 response does not distinguish between a successful revocation and a failed request. To confirm the token is no longer valid, attempt to use it with any REST API endpoint. A revoked token will return HTTP 401 Unauthorized with error code 5002 "Invalid token". For example, attempt to fetch the list of dashboards using the token being tested: curl -X GET "https://$SISENSE_URL/api/v1/dashboards" \ -H "Authorization: Bearer $TOKEN_TO_REVOKE" \ -H "Accept: application/json" Replace $SISENSE_URL with the organization's Sisense URL and $TOKEN_TO_REVOKE with the bearer token that was revoked. If the token has been successfully revoked, the response is: HTTP/2 401 Unauthorized { "error": { "code": 5002, "message": "Invalid token.", "status": 401, "httpMessage": "Unauthorized" } } If the token is still valid, the request succeeds and returns the dashboard list instead, meaning revocation did not work. Review the DELETE request for the correct Sisense URL, user ID, and an admin token with sufficient privileges, and try again. If admin privileges are not available, or the DELETE endpoint continues to fail, use the renew endpoint covered above as an alternative way to invalidate the token. Conclusion For most situations, letting a bearer token expire on its own is sufficient. When immediate revocation is required, the DELETE endpoint revokes a token generated through the token generation API without issuing a replacement, but only with admin privileges. The renew endpoint works for either token type and for any level user, but always issues a new token in the process and invalidates every token the user currently holds, not just one. Renewing and not storing the new generated token functionality acts as deletion in most aspects.

APIs

Connection Tool - Programmatically Remove Unused Datasource Connections, and List All Connections

Connection Tool - A Tool to Programmatically Remove Unused Datasource Connections, and List All Connections Managing connections within your Sisense server can become complex over time, if there are a large number of connections, and connections are often added, and replace earlier datasource connections. In some scenarios unused connections can accumulate, potentially cluttering the Connection Manager UI with no longer relevant connections. Although unused connections typically represent minimal direct security risk, it's considered best practice to maintain a clean, organized list of connections, and in some scenarios it can be desired to remove all unused connections. Sisense prevents the deletion of connections actively used in datasources, safeguarding your dashboards and datasources from disruptions. However, inactive or "orphaned" connections remain after datasources are deleted or a connection is replaced, potentially contributing to unnecessary UI complexity in the connection manager UI. Connections can be of any type Sisense supports, common types include various SQL connections, Excel files, and CSV files, as well as many data providers, such as Big Panda. This tool can also be used to list all connections, with no automatic deletion of unused connections. Introducing the Sisense Connection Prune Tool The Sisense Connection Prune Tool is a Python-based Sisense API based tool designed to programmatically identify and delete unused connections. It generates a CSV report listing all connections and their associated datasources, streamlining your connection management process. If desired, it can automatically remove all unused connections automatically from a Sisense server. Using the Tool, sourcing the Virtual Environment, generating the Connection CSV CSV Output of Used Connections and Associated Datasources CSV opened visually to view as Table, Excel and other programs and text editors can open CSV files Sisense Connection Prune Tool README Here's the full README included with the tool: # Sisense Connection Prune Tool A command-line tool to list used data connections and prune unused Sisense connections via CSV. It allows you to generate a CSV file of all connections and their dependencies, then delete those connections if needed, after removing the connections to keep from the CSV. ## Features - **Dry Run Mode**: Simulate deletions without making any changes. - **CSV-Based Flow**: Easily inspect and list connections to remove before deletion. - **Logging**: Extensive logs if needed. - **Error Handling**: Clear and descriptive messages for issues encountered during execution. ## Usage 1. **Activate the Virtual Environment** After downloading this project folder, activate the Python virtual environment bundled with it that includes all Python dependencies. - **Windows**: `venv\Scripts\activate` - **macOS/Linux**: `source venv/bin/activate` 2. **Configure the Tool** Open the `config.yaml` file and set your Sisense server URL, bearer token, CSV file path, and log file path. For example: ```yaml server_url: "https://your.sisense.server" bearer_token: "your_bearer_token_here" dry_run: true csv_file_path: "connections.csv" log_file_path: "connection_tool.log" ``` - **server_url**: The URL of your Sisense instance. - **bearer_token**: Your Sisense API token for authentication. - **dry_run**: If set to `true`, deletions will be simulated (no real deletions). - **csv_file_path**: Where the CSV file should be created and read from. - **log_file_path**: Where log file will be stored. 3. **Run the Tool** ```bash python3 ConnectionPruneTool.py ``` You will be prompted to choose an option: 1. **Generate connection CSV** - Fetches all Sisense connections. - Immediately removes (or simulates removing, if `dry_run` is `true`) any connection with no dependencies. - Writes all remaining connections and their dependencies to the CSV file. - **Important**: Inspect the CSV file and remove lines for any connections you want to **keep**. 2. **Delete connections from CSV list** - Reads the CSV file. - Removes or simulates removing each connection still listed. - Provides a summary report of which connections were deleted or bypassed. 4. **Review the Logs** Check the file specified in `log_file_path` for a record of all actions taken or simulated if needed. This is helpful for understanding what happened during each run and diagnosing any issues. ## Example Workflow 1. **Generate CSV** ```bash python3 ConnectionPruneTool.py # Choose option 1 when prompted ``` After generation, open the CSV file and **delete rows** corresponding to any connections you want to **keep**. 2. **Delete Connections** ```bash python3 ConnectionPruneTool.py # Choose option 2 when prompted ``` The tool will read the CSV and delete the remaining listed connections (or simulate deletion, if `dry_run` is enabled). ## Notes - Unused connections are removed automatically in step 1, without a CSV step - To keep a connection, remove its line from the CSV before proceeding with deletion. - If `dry_run` is set to `true`, no actual deletions will occur, only simulated logs and printed messages. - The log file will be cleared at the start of each run, so be sure to review or archive logs (or change log file name in config), if needed. This is a command-line tool to list used data connections and prune unused Sisense connections, in general and via a CSV list. It allows a user with a data admin or higher bearer token to generate a CSV file of all connections and their dependencies, then delete those connections if needed, from the remaining connections in the CSV. Example Output: Deleted unused connection: Old_DB_Connection (ID: 123abc) CSV file generated at connections.csv. It contains 25 row(s) of active connections. Please review and remove lines for connections you want to keep before running deletion step by running tool again. Remaining lines will be deleted in deletion mode. Summary Report: Total lines in CSV (active used connections): 25 Deleted Unused Connections: - Old_DB_Connection No connections were bypassed. API Endpoints Used Retrieve connections: GET /api/v2/connections Retrieve dependencies: GET /api/v2/connections/{connection_id}/getAllDependencies Delete connection: DELETE /api/v2/connections/{connection_id} Full Code connections.py - Uses Sisense API endpoints to: Fetch all connections (GET /api/v2/connections). Retrieve datasource dependencies for a specific connection (GET /api/v2/connections/{connection_id}/getAllDependencies). Delete a specific connection (DELETE /api/v2/connections/{connection_id}). from helperFunctions import load_config, api_get, api_delete config = load_config() headers = {"Authorization": f"Bearer {config['bearer_token']}"} base_url = config["server_url"] # Retrieve all connections from Sisense def get_all_connections(): endpoint = f"{base_url}/api/v2/connections" return api_get(endpoint, headers) # Retrieve dependencies of a specific connection def get_connection_dependencies(connection_id): endpoint = f"{base_url}/api/v2/connections/{connection_id}/getAllDependencies" return api_get(endpoint, headers) # Delete a specific connection def delete_connection(connection_id): endpoint = f"{base_url}/api/v2/connections/{connection_id}" return api_delete(endpoint, headers) helperFunctions.py - Uses the Requests library to handle API requests (GET/DELETE). Catches and logs API errors. Uses PyYAML to read the config.yaml file for configuration. import yaml import requests import logging # Load configuration from YAML file def load_config(): with open("config.yaml", "r") as file: return yaml.safe_load(file) # Configure logging settings def setup_logging(log_file): logging.basicConfig( filename=log_file, level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s", ) # Perform a GET request with error handling def api_get(endpoint, headers): try: response = requests.get(endpoint, headers=headers, verify=False) response.raise_for_status() return response.json() except requests.RequestException as e: logging.error(f"GET request failed: {e}") print(f"Error during GET request: {e}") return None # Perform a DELETE request with error handling def api_delete(endpoint, headers): try: response = requests.delete(endpoint, headers=headers, verify=False) response.raise_for_status() return response except requests.RequestException as e: logging.error(f"DELETE request failed: {e}") print(f"Error during DELETE request: {e}") return None ConnectionPruneTool.py - Serves as the entry point for the entire tool. Implements a CLI for user interaction. Invokes connections.py and helperFunctions.py to retrieve, analyze, and optionally delete Sisense connections. Uses Pandas to build a DataFrame of connection details and writes the results to a CSV file. Reads back the CSV file to remove selected connections after manual edits. Manages logs and prints summary reports to the terminal. import pandas as pd import logging import os from connections import ( get_all_connections, get_connection_dependencies, delete_connection, ) from helperFunctions import load_config, setup_logging # Load config yaml config = load_config() setup_logging(config["log_file_path"]) # Clear log file at start open(config["log_file_path"], "w").close() dry_run = config["dry_run"] csv_path = config["csv_file_path"] def generate_connections_csv(): """ Retrieves all connections from Sisense, deletes any that have no dependencies (unless in dry_run mode), and writes the remaining used connections and their dependent data models to a CSV file. """ # Create or clear existing CSV open(csv_path, "w").close() connections = get_all_connections() if connections is None: logging.error("Failed to retrieve connections.") print("Failed to retrieve connections.") return data = [] deleted = [] bypassed = [] # Go through each connection returned from the API for conn in connections: dependencies = get_connection_dependencies(conn["oid"]) if dependencies is None: logging.warning( f"Failed to retrieve dependencies for: {conn['name']} ({conn['oid']})" ) print( f"Failed to retrieve dependencies for: {conn['name']} ({conn['oid']})" ) bypassed.append(conn["name"]) continue # If no dependencies, optionally delete the connection (not in dry-run) if not dependencies: action_msg = "[Dry Run] Would delete" if dry_run else "Deleted" log_str = ( f"{action_msg} unused connection: {conn['name']} (ID: {conn['oid']})" ) print(log_str) logging.info(log_str) if not dry_run: try: response = delete_connection(conn["oid"]) # If response is None, treat it as a failed deletion if response is None: logging.error( f"Failed to delete unused connection: {conn['name']} ({conn['oid']})." ) print( f"Error deleting unused connection: {conn['name']} ({conn['oid']})" ) bypassed.append(conn["name"]) else: deleted.append(conn["name"]) except Exception as e: logging.error( f"Exception while deleting unused connection: {conn['name']} ({conn['oid']}) - {e}" ) print( f"Error deleting unused connection: {conn['name']} ({conn['oid']})" ) bypassed.append(conn["name"]) else: # If the connection is used, add each dependency row to CSV. # Use a fallback value if 'title' or 'oid' is missing. for dep in dependencies: dep_title = dep.get( "title", "NULL TITLE Share Datasource with associated Bearer Token user to include in CSV", ) dep_oid = dep.get("oid", "NULL OID") data.append( { "Connection Name": conn["name"], "Connection ID": conn["oid"], "Elasticube/Data Model Name": dep_title, "Elasticube/Data Model ID": dep_oid, } ) # Create a DataFrame of only the used connections (with datasource dependencies) df = pd.DataFrame(data) df.to_csv(csv_path, index=False) row_count = len(df) logging.info(f"Generated CSV at {csv_path}") print( f"CSV file generated at {csv_path}. " f"It contains {row_count} row(s) of used connections.\n" "Please review and remove lines for connections you want to keep " "before running deletion step by running tool again. Remaining lines will be deleted in deletion mode." ) # Summaries for auto-deleted (unused) connections print("\nSummary Report:") print(f"Total lines in CSV (active used connections): {row_count}") if deleted: print("\nDeleted Unused Connections:") for d in deleted: print(f" - {d}") else: print("\nNo connections were deleted in this step.") if bypassed: print("\nBypassed Connections:") for b in bypassed: print(f" - {b}") else: print("\nNo connections were bypassed in this step.") def delete_connections_from_csv(): """ Reads the CSV (remaining lines after user review, removing lines for connections to keep), then deletes each connection listed. If a delete fails or returns None, the connection is logged and added to 'bypassed'. """ if not os.path.exists(csv_path): print( "CSV file does not exist. Please generate it first or fix the config path." ) return df = pd.read_csv(csv_path) deleted = [] bypassed = [] for _, row in df.iterrows(): conn_id = row["Connection ID"] conn_name = row["Connection Name"] action_msg = "[Dry Run] Would delete" if dry_run else "Deleted" log_str = f"{action_msg} connection: {conn_name} ({conn_id})" print(log_str) logging.info(log_str) if not dry_run: try: response = delete_connection(conn_id) if response is None: logging.error( f"Failed to delete connection: {conn_name} ({conn_id})" ) print(f"Error deleting connection: {conn_name} ({conn_id})") bypassed.append(conn_name) else: deleted.append(conn_name) except Exception as e: logging.error( f"Exception while deleting connection: {conn_name} ({conn_id}) - {e}" ) print(f"Error deleting connection: {conn_name} ({conn_id})") bypassed.append(conn_name) # Print summary report print("\nSummary Report:") if deleted: print("Deleted Connections:") for d in deleted: print(f" - {d}") else: print("No connections were deleted.") if bypassed: print("\nBypassed:") for b in bypassed: print(f" - {b}") else: print("No connections were bypassed.") if __name__ == "__main__": # If there is no CSV file found, select step 1 automatically if not os.path.exists(csv_path): print( "No CSV file found; defaulting to generating connections CSV. " "Correct config if CSV file name has changed." ) generate_connections_csv() else: choice = input( "Choose an option:\n" "1 - Generate connection CSV\n" "2 - Delete connections from CSV list\n" "Enter your choice (1 or 2): " ) if choice == "1": generate_connections_csv() elif choice == "2": delete_connections_from_csv() else: print("Invalid option. Please enter '1' or '2'.") Conclusion By automating the detection of inactive connections and simplifying their removal, the Sisense Connection Prune Tool reduces clutter in the Sisense server Connection Manager UI while minimizing the risk of unintentionally impacting active datasources. Whether you opt for a dry-run mode to review potential deletions in a generated CSV file, or to simply list connections, or proceed with the full removal of unused connections, this tool offers a clear, flexible, and reliable approach to keeping your connections organized. A full copy of the tool, is attached below.

APIs

Create a dashboard handbook from dashboard IDs [Windows]

Step-by-Step Guide 1. Prepare the Config File Before running the script, edit the settings.yml file with your Sisense server information and dashboard IDs you want to process. Example settings.yml: username: test@test.com password: Test12345!@#$% url: http://localhost:8081 dashboard_ids: - 68526ec76704160c3c34fd77 - 685a79a130f47d228cb66e40 This configuration file instructs the script on which dashboards to process and how to connect to your Sisense server. 2. Understand Script Behavior The Dashboard Handbook Creator script: Creates a Word document with the dashboard name, widget name, description, and widget images. Searches the local folder for widget images. Downloads missing widget images from your Sisense server. Skips already downloaded widgets for speed. Important: Generating widget images consumes server resources and may impact performance if multiple dashboards are processed simultaneously. It’s recommended to: Run the script for a few dashboards at a time. Run it during off-hours to reduce load. 3. Run the Script Place the script and settings.yml in the same folder. Execute the script by running doc.exe . Screenshot: 4. Access the Generated Document Once complete, the script creates a .docx file in the folder containing: Dashboard names Widget names Widget descriptions Widget images Screenshot: Limitations: Does not work with reverse proxy setups. Compatible only with Sisense for Windows (tested on version 20.25.3.10026). Conclusion The Dashboard Handbook Creator is a useful tool to generate comprehensive dashboard documentation automatically. By configuring your settings and understanding the resource requirements, you can streamline your documentation process and improve knowledge sharing within your organization. References/Related Content Sisense API documentation Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.

APIs

API Bearer token lifecycle in Sisense [Linux]

Background Personal API Bearer tokens allow you to authorize your requests to the Sisense API endpoints. See Using REST API for more details. Creation Each API Bearer Token is bound to a user who creates it and inherits permissions and access level. One user may create multiple tokens using one of the three APIs: POST /api/v1/authentication/login - generates a Bearer token based on the provided username/password. Only available to users who have Sisense credentials. GET /api/v1/authentication/tokens/api - generates a Bearer token of the currently logged-in user. Can be used by users who do not have Sisense native credentials, such as the SSO-integrated users. POST /api/v1/authentication/tokens/api/renew - invalidates all previously issued Bearer tokens of the user and creates a new one. Revocation The user's API Bearer token can be invalidated due to certain user-level or system-level events. It is important to note that there is no way to invalidate a particular token of a user while keeping their other tokens valid, except by waiting for the token to expire. All events mentioned below invalidate all tokens for a particular user (user-level events) or all users in the system (system-level events). User events: Sending a POST /api/v1/authentication/tokens/api/renew request. Sending a DELETE /api/v1/authentication/admin/tokens/{tokenType} request (tokenType = api, users = userId). For SSO JWT users: If the [User Profile] > [API Token] feature is turned off: When a user logs out of Sisense, by either clicking the Logout button or calling a logout endpoint, such as /api/auth/logout. The Bearer token may be invalidated during a build of the Elasticube that is owned by an SSO JWT user and has Custom Code tables. System events: Changing the [Support Cross-Site Cookies for Embedding] mode in the [Security Settings] (e.g., from Default to None). Switching the [Session Management] mode from [Cookie] to [Session Inactivity] and vice versa. Sending the POST /api/v1/authentication/admin/logout_all_users request. Changing the secret in the extended [Security Settings]. Expiration The expiration of Bearer tokens is a system-wide setting introduced in the L2024.1 version. The state of this feature can be viewed by running the GET /api/v1/settings/system request. The corresponding parameter is called [apiTokenExpiration] under the [authentication] section. When [apiTokenExpiration] is enabled, the token expiration is defined based on the Session Management duration in the Security Settings (either Cookie or Session Inactivity, depending on the selected mode). You can view the expiration time of a particular API Bearer token by JWT-decoding it and checking the ‘exp’ field. More details: https://docs.sisense.com/main/SisenseLinux/sisense-bearer-tokens.htm . Renew The API bearer tokens include the expiration date in their structure. As such, it is not possible to renew a particular API Bearer Token. Instead, you can either generate a new token, or use a renew endpoint to invalidate all previously generated tokens for this user and create a new token. What [User profile > API Token] controls The [User Profile] > [API Token] system-wide parameter controls a few aspects of the Bearer tokens. When you enable the token, the following changes are applied in the system: All users will see an API Token in their User Profile. Users can view and renew (rotate and create a new one) their API Bearer tokens. Logout no longer invalidates all API Tokens for the SSO JWT users. Execution of the Custom Code table no longer invalidates all API Tokens of the SSO JWT users. POST /api/v1/authentication/tokens/api/renew endpoint becomes available in the system. Best practices If you build an API integration, you may want to consider creating a dedicated Sisense user to execute API requests. Finish configuring the authentication and cookie settings in your environment before proceeding to develop API integration to avoid unexpected system-wide API Token revocations. If you plan to enable token expiration, carefully consider the session duration, as it will also affect the API Bearer Tokens. If you plan to use the API Bearer tokens as JWT SSO users, consider enabling [User Profile] > [API Token] setting to avoid token invalidations after some user actions. In case of the token expiration, implement logic that would regularly renew the token in your external integration. Conclusion API Bearer tokens in Sisense are user-specific, inherit user permissions, and can be created via three different API endpoints, including SSO users. All tokens of a user can be invalidated due to specific user/system events; individual token revocation is not supported except via expiration. Expiration is controlled by a system-wide setting (“apiTokenExpiration”) and is linked to session management configurations. The [User Profile] > [API Token] setting modifies how tokens work for SSO JWT users, improving persistence after logout or custom code execution. References/Related Content https://sisense.dev/guides/restApi/using-rest-api.html https://docs.sisense.com/main/SisenseLinux/sisense-bearer-tokens.htm https://community.sisense.com/kb/apis/beginner-sisense-rest-api-tips/9043 https://community.sisense.com/kb/apis/curl-api-usage/9049 https://community.sisense.com/kb/apis/access-sisense-api-from-postman/9048 Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.

APIs

Get Widget’s Values Directly From The ElastiCube (API Request)

Developers: REST API

Description Shifting between external sources that are based on different scripting languages is not an easy task. When there is a requirement to query a secured widget's data to an external source (Such as JQuery, JavaScript,HTTP etc.), you will need to utilize the REST API. A quick example will be grabbing a widget's data to a public website or a customized company's mail report. Prerequisites Sisense Admin permission REST API Access ElastiCube and linked dashboard with widgets PostMan application installed - https://www.getpostman.com/apps Granted access to the machine (IP) that is going to execute the API request against the Sisense Server - Check that the dashboard is accessible from the external machine that execute the API request. Steps a. Widget's JAQL Preparation and Save it Make the the JAQL code as short as possible by "starring" the formulas that are used in the widget - https://docs.sisense.com/main/SisenseLinux/reusing-formulas.htm To get the widget's JAQL code - Edit Widget > Click on F12 to open developer tools > Open Console > Clear Content > type - prism.debugging.GetJaql(prism.activeWidget).replace(/(\r\n|\n|\r|\t)/gm, ""); and then hit enter 3. Copy the JAQL code to notepad - without the quotes b. Create the Curl and URL Request 1. Go to the Admin Page > Click on REST API reference > Open REST API 0.9 (top right of the screen) 2. Go to - Post> elasticubes/{elasticube}/jaql 3. Copy the JAQL code into the request's body 4. Copy the ElastiCube ID from the JAQL code (data source section) into the ElastiCube input without the quotes. For example: 5. Hit Run and validate the response. A correct response will appear in bottom: 6. Copy the Curl and Request URL to notepad: c. Create authentication token to query the ElastiCube 1. Go to the Admin Page > Click on REST API reference > Open REST API 1.0 (top right of the screen) 2. Go to - Post> authentication/login 3. Insert your username/password and hit execute 4. Copy the given access token from the response section without quotes to notepad d. Generate the Final API Request 1. Open PostMan and create a new POST request 2. Enter the Request URL - Place Sisense Request URL and ElastiCube ID taken from the step B. 3. Copy the the body tab (choose raw option) the entire JAQL code from step A. 4. Open Authorization tab > choose Bearer type > Insert your authentication token from Step C. 5. Open Headers section and add: Content-Type, application/json Accept, application/json 6. Hit send to get the API call response that will include your widget data values Response Example: 7. Click on "code" (right side of the page), to covert the API request to any scripting language that is required.

APIs

How to activate Sisense license on Linux without web access

How to activate Sisense license without web access on Linux This article explains how you can activate a license in your new Sisense installation without access to the Sisense website in the browser. Usual activation In the usual activation, you must navigate to the Sisense URL (printed in the installation logs) to enter your license credentials or specify your offline activation key in the browser. When to use Sometimes, you may want to configure Sisense settings or restore a backup before granting access to the Sisense web application. Restoring a backup requires your Sisense installation to be already activated. In case you would like to block web access to the application before the backup is restored, you can follow the steps below to activate the license from the server side. Activation steps You will need access to the machine with configured kubectl commands (bastion machine in Cloud installation or cluster machine for on-prem Kubernetes deployments).. Ensure that api-gateway pod is running in the system: kubectl get po -n sisense -l app=api-gateway Execute into the api-gateway pod (in case there are multiple replicas, you can enter any of the pods): kubectl exec -it -n sisense $(kubectl get po -n sisense -l app=api-gateway -o name | tail -n 1) -- bash Note. If you use a non-default namespace, replace -n sisense with the correct namespace name. Use the following command to activate your license (replace email and password with your license credentials): curl 'http://localhost:8456/license/activate' \ -H 'Content-Type: application/json' \ --data-raw '{"email":"your_license@sisense.com","password":"pass"}' Wait until all pods transition from Init:4/6 to Running state: kubectl get po -n sisense -w Conclusion You can activate a license in your Sisense installation by sending a request from within the API gateway container instead of a public web request. This method can be used to prevent access to the web application until the backup is restored in a new environment. Related Resources: https://docs.sisense.com/main/SisenseLinux/activating-sisense-on-linux.htm Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this please let us know.

APIs

REST API - Adding Data Level Security

Developers

Developers: REST API

Legacy

When building code to automate the process of adding users (or groups), it may be beneficial to add security around those users. Follow the steps below to learn how to add data level security through the REST API: Step 1 From your SiSense home page, navigate to the Manage tab and choose the option for REST API. From here, click on the link to the REST API Reference interface. Step 2 From here, choose the 0.9 version and expand the Elasticube section and scroll down to the POST /elasticubes/datasecurity section. Step 3 The sample code below shows a valid JSON object to use as part of the REST API request. Starting from the sample code, replace the value for party with a user identifier that already exists in your system. Then paste the code into the REST API interface and click run. You should see a response of 200, which indicates a successful operation. [{ "server": "LocalHost", "elasticube": "Sample Lead Generation", "table": "Lead Generation", "column": "Country", "datatype": "text", "shares": [{ "party": "5c0f85690ca2f66cc242e266", "type": "user" }], "members": [ "United States", "England" ] }] Notes The server name value is case sensitive, so make sure it matches with your system. The sample provided is specific to one of the sample databases that comes with SiSense. To modify this to a different system, just update necessary fields to include your specifications. The sample provided is an array that consists of a single element. This could be modified to contain several entries all sent at once.

APIs

Reverting the proxy URL (base URL) setting in Sisense Linux L2021.1.0+

Cloud

Configuration & Design Tips

Linux

On-Prem

Reverting the proxy URL (base URL) setting in Sisense Linux L2021.1.0+ Introduction Sisense allows configuring the application to be accessed behind a reverse proxy. There are two main steps to do so: Create and configure a reverse proxy server (e.g. Nginx or Apache) to proxy traffic from the desired URL to the Sisense server. Update the Proxy (Base) URL in the Sisense settings. In cases when the first step was not finished or was misconfigured, proceeding with the second step may lock you out of the application, preventing you from reverting the Proxy URL changes in Sisense. This guide explains how to revert the changes via REST API and Sisense admin credentials. For more details about the proxy configurations please refer to https://community.sisense.com/t5/knowledge-base/reverse-proxy-with-nginx-ssl-configuration/ta-p/5358 Step-by-Step Guide Option 1 - API request Generating a Bearer token via REST API Send the POST /api/v1/authentication/login request: Body (Using x-www-form-urlencoded ) Property Value username The username you log in to Sisense with password The password you log in to Sisense with The resulting HTTP request should look like: POST /api/v1/authentication/login HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Example of the content: username=user%40example.com&password=12345678 The response body will contain a JSON with the “access_token” entry, for example: { "success" : true, "message" : "" , "access_token" : "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiNjcyZTEzZjk4YzI0NmEwMDFkNTQ0ZjRjIiwiYXBpU2VjcmV0IjoiZmVkM2EyYzctMjdkYS1kNGNjLWFjNTktYmRlNTVkZWI3NmJlIiwiYWxsb3dlZFRlbmFudHMiOlsiNjcyZTEzZjk4YzI0NmEwMDFkNTQ0ZjU5Il0sInRlbmFudElkIjoiNjcyZTEzZjk4YzI0NmEwMDFkNTQ0ZjU5IiwiZXhwIjoxNzMxNjgwMzk0LCJpYXQiOjE3MzEwNzU1OTR9.UPEtpUkThvG8nWoGqNNDozZZyS-BjeTjjCyZodof8qg" , "profile" : {}, "tenantId" : "672e13f98c246a001d544f59" , "roleName" : "super" , "userId" : "672e13f98c246a001d544f4c" } Sending a POST request to update Sisense settings Send the POST /app/configuration/configurations/system/list request: Headers : Authorization: “Bearer eyJhbGciO… ” * Replace the token with a token generated in the previous step. Body (raw, JSON) : { "base" :{ "webServer.proxyurl" :null}} Wait 3-5 minutes until Sisense applies the changes and restarts the relevant services. Log into Sisense using a direct non-proxied address. Option 2 - Server Access (for On-Prem installations) Connect to a server with configured kubectl: In case of a single node - the Sisense server In case of a Sisense-installed Kubernetes - the first node of the cluster In case of Cloud Kubernetes - the bastion machine Run the following commands: 1. kubectl exec -it -n sisense $(kubectl get po -n sisense -l app=configuration -o name | tail -n 1) -- bash * Replace the “sisense” namespace if you use a non-default namespace 2. node node_modules/@sisense/sisense-configuration/bin/sisense-conf setbase webServer.proxyurl null -p -c ${ZOOKEEPER_CONN_STRING} 3. Wait 3-5 minutes until Sisense applies the changes and restarts the relevant services. 4. Log into Sisense using a direct non-proxied address. Conclusion It is important to deploy and configure a reverse proxy server before introducing the configuration changes to the Sisense application. Failing to do so may lock you out of Sisense UI and you will have to use one of the above programmatic approaches to revert the configuration changes. Relevant Content: Docs: https://docs.sisense.com/main/SisenseLinux/configuration-manager-sisense-documentation.htm Dev Docs: https://sisense.dev/guides/restApi/v1/?platform=linux&spec=L2023.11#/authentication

APIs

Exporting Options in SisenseJS

CSV

Sisense.JS

Exporting Options in SisenseJS SisenseJS is a powerful tool that allows embedding widgets from Sisense into external applications. Despite it being a very straightforward way of embedding, SisenseJS has some missed functionality. For example, there are no OOTB methods to export widget's data into CSV and Excel. In this article, we will implement this functionality. We will use a combination of Sisense REST API endpoints for exporting and capabilities of SisenseJS in order to prepare payloads. In our sample, we will create the required logic for one widget. You can replicate this logic for every widget in your implementation. Common logic When you load a dashboard, you need to save its object. For these purposes we will use a variable [currentDashboard]: Sisense.connect('https://example.com').then(function (app) { app.dashboards.load(dashboardId).then(function (dashboard) { currentDashboard = dashboard; //Further logic to render widgets on the page }); }); In terms of our task we need to get the widget’s object we are going to export. To get this object you can run the following logic: const getWidget = (widgetId) => { return currentDashboard.widgets.get(widgetId).$$model; } This function returns the widget’s object. We do have the widget’s object, so we know the widget’s metadata and also we have information about the dashboard’s filters. We could use this to build a query manually, but it would be quicker to utilize the SisenseJS capabilities. When we call the function getWidget() we need to provide the widget’s identifier as an argument: const currentWidget = getWidget('63cfd64645e8ec00324a13aa'); //Replace "63cfd64645e8ec00324a13aa" with your widget's identfier. Note, that it should be loaded and rendered As a result, we will get the widget’s model. Later we will use it to prepare the payload. Also, we need to implement some functions to generate unique identifiers. This is not a mandatory step, but it can be useful if you want to cancel queries. Sample of the function: function uuidv4() { return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) { var r = Math.random() * 16 | 0, v = c == 'x' ? r : (r & 0x3 | 0x8); return v.toString(16); }); } Excel To generate payload for Excel we will use the function below: const prepareExcelPayload = (widget) => { const query = widget.dashboard.$query.buildWidgetQuery(widget); //Use Sisense capabilities to prepare query query.queryGuid = uuidv4(); //Generate queryGuid query.dashboard = widget.dashboardid || widget.dashboard.oid; query.culture = "en-us"; //This can be set from navigator.language query.format = 'pivot'; query.metadata.forEach(function(m) { if (m.jaql && m.jaql.dim) { //We need to remove [table] and [column] delete m.jaql.table; delete m.jaql.column; } }) return JSON.stringify({ query: query, options: {} }); //Return payload for exporting in Excel } Once the payload is prepared, we can send it to Sisense’s endpoint /engine/excelExport to retrieve the prepared Excel file. After this, we need to load the generated Excel file explicitly. Code: function getExcel(widget) { const xhttp = new XMLHttpRequest(); xhttp.withCredentials = true; //This will be cross-domain request, so we force the browser to add cookies xhttp.onreadystatechange = function () { if (xhttp.readyState === 4 && xhttp.status === 200) { const a = document.createElement('a'); a.href = window.URL.createObjectURL(xhttp.response); a.download = widget.title ? `${widget.title}.xlsx` : 'Details.xlsx'; a.style.display = 'none'; document.body.appendChild(a); a.click(); } }; xhttp.open("POST", `${sisenseUrl}/engine/excelExport`); xhttp.setRequestHeader("Content-Type", "application/json"); xhttp.responseType = 'blob'; xhttp.send(payload); } CSV A function to generate query: const prepareCSVPayload = (widget) => { let query = widget.$query.buildWidgetQuery(widget, 'exportToCSV'); query = Object.assign(query, { format: "csv", isMaskedResponse: true, download: true, count: 0, offset: 0 }); query = widget.dashboard.$query.createJaqlRequestConfig(query); query.metadata.filter((item) => { return defined(item.format); }) return { data: encodeURIComponent(JSON.stringify(query)) }; } This function returns a payload, which can be sent at the endpoint `/api/datasources/${ widget.datasource.title }/jaql/csv`. As you can see, this endpoint depends on the datasource’s title. Since the dashboard’s datasource can differ from the widgets’ datasources, I do recommend getting the correct datasource from the widget itself and for sure you need to avoid any hardcoded values. function getCSV(widget) { let csvDownloader = new XMLHttpRequest(); csvDownloader.open('POST', `/api/datasources/${widget.datasource.title}/jaql/csv`); csvDownloader.responseType = 'arraybuffer'; csvDownloader.onload = function () { if (this.status === 200) { let filename = ""; const disposition = csvDownloader.getResponseHeader('Content-Disposition'); if (disposition && disposition.indexOf('attachment') !== -1) { const filenameRegex = /filename[^;=\n]*=((['"]).*?\2|[^;\n]*)/; const matches = filenameRegex.exec(disposition); if (matches != null && matches[1]) filename = matches[1].replace(/['"]/g, ''); } const type = csvDownloader.getResponseHeader('Content-Type'); const blob = typeof File === 'function' ? new File([this.response], filename, { type: type }) : new Blob([this.response], { type: type }); if (typeof window.navigator.msSaveBlob !== 'undefined') { // IE workaround for "HTML7007: One or more blob URLs were revoked by closing the blob for which they were created. These URLs will no longer resolve as the data backing the URL has been freed." window.navigator.msSaveBlob(blob, filename); } else { const URL = window.URL || window.webkitURL; const downloadUrl = URL.createObjectURL(blob); if (filename) { const a = document.createElement("a"); if (typeof a.download === 'undefined') { window.location = downloadUrl; } else { a.href = downloadUrl; a.download = filename; document.body.appendChild(a); a.click(); } } else { window.location = downloadUrl; } setTimeout(() => { URL.revokeObjectURL(downloadUrl); }, 100); // cleanup } } }; csvDownloader.withCredentials = true; csvDownloader.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); $.param(payload); csvDownloader.send(payload); } I hope you find this article useful and leverage the knowledge shared about exporting widgets data in different formats. Please share your experience in the comments!

APIs

How to unblock users after failed login attempts

users management

How to unblock users after failed login attempts Protecting user credentials can't be overstated in any secure system. Security measures such as locking users after multiple failed login attempts are critical in preventing brute-force attacks. However, while this feature strengthens security, it can also become a source of frustration for legitimate users who mistakenly enter the wrong password multiple times. In this article, we’ll walk you through the process of unblocking users who have been locked out after multiple failed login attempts using Sisense’s REST API. We will explore the challenges this feature presents and how API calls can streamline the user management process for administrators. Why Are Users Locked Out? Sisense, like many other platforms, implements security protocols to temporarily lock users out after a series of incorrect password attempts. The aim is to prevent unauthorized access to sensitive data by blocking brute-force attacks. While this is a necessary security measure, it can also affect valid users who may have simply mistyped their passwords several times. The lockout settings can be managed under Admin -> Security&Access -> Security Settings Using the REST API to Unblock Users To allocate the blocked user ID, simply go to Admin -> Users perform the email search, click on the pencil icon on the right side, and copy the user identifier. With Sisense's REST API, you can easily unblock the users. To perform unblocking go to Admin -> REST API -> v1 -> default Expand the POST request /account/remove_lockout/{user_id}, click “Try It Out”, paste the user's ID into the user_id field, and click execute After this user will be unblocked. Related Content: REST API Dev Docs: https://sisense.dev/guides/restApi/v1/?platform=linux&spec=L2023.11#/account

APIs

Exporting Sisense User Lists to CSV

Exporting Sisense User Lists to CSV Exporting Sisense users requires using the REST API. While the user list is visible under Admin > User Management > Users , there is no option to download and manipulate this data directly. From The Users Info, Admin can generate some insights, Such as: Review Active/Inactive Users Review Last Login Group the Users by Roles Sisense Provide 2 endpoints to get the list of all users. Version 0.9 --> Get /users Version 1.0 --> Get /users The sample Python script below utilizes the GET /users endpoint on version 1.0 Implementation Steps Open Python and Install the relative libraries in case needed Update the Following Variables In the Python Script: Personal Server Token - Sisense Authentication Token. Can be achieved By Api Version 1.0 - Post /authentication/login CSV Path - Local PC file path for the CSV to download 3. Run the Script Python Script import json import requests import pandas as pd # Define global variables server = '' # Replace with your actual server URL. for example: https://url.sisense.com token = '' # Sisense Authentication token path = '' """ Define the path variable according to your operating system and file location Example for Windows: path = r'C:\\Users\demo.demo\Desktop\sisense_users.csv' Example for Mac: path = '/Users/demo.demo/Desktop/sisense_users.csv' """ # Fixed variables: `user_columns`, `params`, and `headers` are fixed and should not be updated. user_columns = ['_id','active','roleId','created','tenantId','email','firstName','lastName','userName','lastLogin','lastActivity'] # Define the fields to be retrieved for users params = { "fields": ",".join(user_columns) } headers = { "Authorization": f"Bearer {token}", "Content-Type": "application/json" } # Retrieves user data from the specified server endpoint, filters it based on provided user_columns, and returns a DataFrame. def get_users(server, token, headers, user_columns, params): endpoint = '/api/v1/users' url = f'{server}{endpoint}' try: request = requests.get(url=url, headers=headers, params=params) request.raise_for_status() # Check for request success respond = request.json() user_data = [] for user in respond: user_dict = {} for key, value in user.items(): if key in user_columns: user_dict[key] = value user_data.append(user_dict) # Append dictionary containing all attributes return pd.DataFrame(user_data) except requests.exceptions.RequestException as e: print('Error:', e) return None # Return None or handle error appropriately # Modifies the input DataFrame by converting specific columns to datetime format, renaming certain columns, and saving the DataFrame to a CSV file def modify_df(df_users): # Convert columns to datetime format df_users["created"] = pd.to_datetime(df_users["created"]) df_users["lastLogin"] = pd.to_datetime(df_users["lastLogin"]) df_users["lastActivity"] = pd.to_datetime(df_users["lastActivity"]) # Rename specific columns in the DataFrame df_users.rename(columns={'_id': 'user_id', 'userName': 'user_name', 'firstName': 'first_name', 'lastName': 'last_name', 'active': 'is_active', 'roleId': 'role_id', 'created': 'created_date', 'tenantId': 'tenant_id', 'lastLogin': 'last_login', 'lastActivity': 'last_activity'}, inplace=True) # Reorder columns ordered_columns = [ 'user_id', 'user_name', 'first_name', 'last_name', 'is_active', 'role_id', 'created_date', 'tenant_id', 'last_login', 'last_activity' ] df_users = df_users[ordered_columns] # Save the DataFrame to a CSV file without including the index df_users.to_csv(path, index=False) return df_users # Retrieve users data using the get_users function df_users = get_users(server, token, headers, user_columns, params) # Modify df_users data frame into the final output df_result = modify_df(df_users) # Print the first few rows of the modified DataFrame print(df_result.head()) # Print a message indicating the end of the program print("program completed")

UserReplaceTool - Automating Dashboard Ownership Transfers - Useful for Deleting User Accounts

Manually Revoking a Sisense Bearer Token

Connection Tool - Programmatically Remove Unused Datasource Connections, and List All Connections

Create a dashboard handbook from dashboard IDs [Windows]

API Bearer token lifecycle in Sisense [Linux]

Get Widget’s Values Directly From The ElastiCube (API Request)

How to activate Sisense license on Linux without web access

REST API - Adding Data Level Security

Reverting the proxy URL (base URL) setting in Sisense Linux L2021.1.0+

Exporting Options in SisenseJS

How to unblock users after failed login attempts

Exporting Sisense User Lists to CSV