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.
