I’m trying to reconcile the user counts shown in the Admin Console → Members tab with what I get via the public API.
Specifically, I’m using this endpoint:
GET /1.0/workspace_memberships?workspace={workspace_gid}&opt_fields=user.email,is_active,is_guest,is_admin,is_view_only
and filtering for users where is_active = true, is_guest = false, and is_view_only = false (which I assume should represent “Members”).
However, the count I get via the API doesn’t match what the Admin Console → Members tab shows.
Can someone clarify:
How does Asana determine who appears under the “Members” tab in the Admin Console?
Which fields (or combination) in the API correspond most closely to that list?
Is there any way to identify “Super Admins”, “Billing Owners”, or “License-holding Members” programmatically (possibly via SCIM or another enterprise API)?
How to get the seats available count ?
ve reviewed the /workspace_memberships and /users endpoints, but none seem to reflect the same filtering logic used in the UI.
Any official guidance or mapping between Admin Console roles and API fields would be really helpful.
Thanks in advance
Triven
The numbers shown in the Admin Console → Members tab often differ from what you see when using the public API, and that’s expected due to how these systems are designed.
The Admin Console pulls data from the organization (domain) level, while the Get the workspace memberships for a workspace endpoint operates at the workspace level. The Admin Console also applies internal filters and includes user states (like pending invites, paused users, or service accounts) that aren’t represented in the public API.
If you’re trying to get a list that roughly matches the “Members” tab, you can use:
GET /workspaces/{workspace_gid}/users?opt_fields=email,is_active,is_guest
Then, filter client-side for:
is_active = true
is_guest = false
This will get you close, though not identical to the Admin Console view.
If you’re on Enterprise, the SCIM APIgives you more accurate org-level data, including user status and licensing info:
GET https://app.asana.com/api/1.0/scim/Users
This endpoint is the closest match to what the Admin Console shows.
Seat availability and billing details aren’t exposed via the public API. Those are derived from internal billing data and can only be viewed in the Admin Console.
I tried using the SCIM /Users endpoint, but it returns more records than what’s shown in the Admin console’s Members tab. Could you please clarify which filters should be applied so the results match the member count displayed in the UI?
Also, don’t you think the data shown in the UI should align with the API responses? Otherwise, it becomes difficult for consumers to trust or rely on the API for accurate reporting.
Thanks,
Hi @dbrdak ,
I understand the organization export API, gives a much better dataset & closer one to the one visible on admin portal.
POST api/1.0/organization_exports
But what I am not able to understand is that the above API starts a job I believe (which is fine), but why does it take almost 2 hours for the API to return roughly 2000 records that we have. I was hitting the GET API under it for almost 2 hours to wait for a download url. I would hope for a background export job to finish within matter of seconds & also return a call back (or download url) sooner.
Could you please assist on getting a workitem in your backlog to improve the performance of that API ?
It’s a bit tricky. I was mostly referring to divisional accounts, where a single organization can include multiple workspaces/ divisions. This is relatively rare to encounter when working with the API, especially if you’re not dealing with identity-related data.
Also, I’m not 100% sure how the Admin Console filters data internally, but I know it’s primarily focused on user management and billing, while the API is more focused on business logic and operational data.
That’s a good point. The API data isn’t incorrect — it’s just different by design. The Admin Console focuses on billing and user management, while the API surfaces workspace memberships and operational data. Because of that, some users that don’t appear in the Admin Console won’t align 1:1 with API results. It’s unlikely that the same filtering logic will be implemented for this endpoint, since the API intentionally provides a more complete dataset.
Could you please submit a support case so we can investigate this more thoroughly?
When creating the ticket, please choose Support Request → API & Integrations → API Questions.
We may need to review specific API responses, and that would be best handled through a private support channel. If we find anything valuable that could help others, I’ll make sure to update this thread.
