Is only ADMIN's Session ID required to perform the administrator job in most of the available API's

Is it mandatory to use the Dundas Administrator’ Session ID only to pass in the API’s performing the admin tasks like -creation of Tenant, creation of new user account, killing of session etc. ?? or we can use any Standard User with Admin privileges. Also if that can be an another User then what will be the Type of User and Seat type.

Admin is not a seat type, but a permissions thing. Anyone in the administrator group can perform admin tasks as far as I know.

Hi Aseem,

Building on David’s answer, you should also use the “API Account” which is a special user that only performs API tasks and cannot log in via API.

1 Like

Hi David,
Thanks. But I found a difference between a user with Admin privileges and a user that is System Administrator. A System Administrator can have more than one instance but the normal user with Admin privileges cannot have.

Hi Jeff,
Thanks, this is helpful.
But I can’t see that ‘API Account’ under Options. I don’t know why.

Hi Jeff,
In our case there will be approx 50 concurrent local users Logging to our Application and will be going through the App having Dundas Dashboards. We need to maintain the Local users sessions programmatically i.e. if exists then keep alive or kill as required and if not then create a new session for user where required and for these functionalities we need to have pass the Admin Session ID to Api’s. The question is for each local user will there be an ‘API Account’ Session open till the session of the local User?


Hi @aseem.sharma,

If you’re not seeing the API User, it might be the version of Dundas BI that you as on as it was a more recent release that added that feature.

As for your user case with managing sessions, you have a few options.

  1. Log on normally and get a session (don’t use logon tokens). Since you are generating a session you can store both the sessionID and the accountID and manage it in your application. If the user logs out of your portal, you can forcefully log them out of Dundas BI since you’ll have everything that you need. The downside to this approach is that it’s less secure since the session ID would be exposed to the browsers query string for a brief period of time. Not the end of the world, but something for which you should be aware.

  2. Create a server-side plugin in .NET that hooks into the CreatingSession event. In doing this, you can use a logon token that is more secure and still be given the session ID that you can manage in your application - similar to above but more secure.

  3. You can stick with the logon token for authentication and simply not worry about managing the sessions in your application. By using a logon token, a session is generated between your user and the Dundas BI application and you never see it. Eventually, through inactivity, the user will be logged out of Dundas BI and redirected to the logon screen. Since in an embedded scenario you wouldn’t want the user to see the logon screen, you would override it with this:

By overriding the logon page, they are returned to your application and you can do whatever you want and manage the experience. The problem with this approach is that a session can be left open which will hog a license from another user until the session is finally timed out (if using concurrent licenses). One possible suggestion is to cut down the session timeout (config setting) but if you do something too aggressive (like 1 min timeout) it can be dirty because you don’t want users losing their view of a dashboard just because they walked away for a minute.

Basically, you have options…

If you’re still struggling, reach out to the Dundas BI support team.

Can anyone suggest me an API through which I can get the ‘Session ID’ of the current logged In user by passing the ‘Account ID’ as a parameter.

Hi Aseem,

You can use the following API to get the user’s session info by passing the “Account ID” as a filter: