How to identify licensed vs guest users via API?

Context

I’m building an integration to retrieve a list of licensed users from our Asana organization. We have 182 total users in our workspace, but only 27 are licensed users (the rest are guests or inactive).

What I’ve tried

1. Workspace Memberships API

According to the [documentation](Get the workspace memberships for a workspace), the workspace memberships endpoint should return `is_guest` field:

```bash

GET /workspaces/{workspace_gid}/workspace_memberships

```

*Result:** `“No matching route for request”`

I also tried:

```bash

GET /users/{user_gid}/workspace_memberships

```

**Result:** `“Full permissions are required to use this endpoint”`

2. Teams-based approach

I’m currently using this workaround:

1. Get all teams in the organization

2. Get members from each team

3. Filter by `@our_organization.com` email domain

4. Remove duplicates

**Result:** Works, but gives ~94 users instead of 27 (includes users with personal teams who aren’t actively licensed)

# 3. Basic Users API

```bash

GET /workspaces/{workspace_gid}/users

```

**Result:** Returns all 182 users, but doesn’t include any licensing information (`is_guest`, `license_type`, etc.)

Questions

  1. **Is the Workspace Memberships API available for all Asana plans?** We have an Enterprise plan.

2. **What OAuth scopes/permissions are required?** Currently using:

  • `users:read`

  • Do I need a specific admin scope?

3. **Is there an alternative API endpoint** to distinguish between licensed and guest users?

4. **Admin Console shows “Licensing Division”** - is this field accessible via API?

My OAuth setup

- Using OAuth 2.0 with authorization code flow

- Scopes: `users:read`, `teams:read`, team_memberships:read, workspaces:read, roles:read

- Organization type: Enterprise

- I am an super admin of the organization

## Desired outcome

A programmatic way (via API) to retrieve only the 27 licensed users from our organization, excluding guests and inactive users.

Any guidance would be greatly appreciated!

-–

## Environment

- Asana Plan: Enterprise

- API Version: 1.0

- Integration type: OAuth 2.0 application

Hi @Michael_Lysik,

I just tested to confirm and this endpoint definitely works:
{baseUrl}/workspaces/{workspace_gid}/workspace_memberships
so I would focus on why that’s not working for you; there must be some subtle issue with the syntax of your call, I would guess.

Hi @Michael_Lysik, and welcome to the Asana Forum!

As @Phil_Seeman mentioned, this error is most likely caused by a small mismatch in your request URL. This specific error is only returned for invalid paths, so it’s not related to permissions or access to the endpoint. I recommend validating the request path using our API Reference or the official Postman Collection to make sure everything matches exactly.

Below are answers to your questions:

  • Is the Workspace Memberships API available for all Asana plans? We have an Enterprise plan.

Yes – this endpoint is available on all Asana plans, including Enterprise. You should not encounter a 402 Payment Required error when using it.

  • What OAuth scopes/permissions are required?

This endpoint returns resources of type workspace_membership, workspace, and user, so read access to all three is required.

At the moment, we don’t yet expose a dedicated workspace_membership:read scope. Because of that, Full Permissions are currently required. Otherwise, the API will return the following error:

{
  "errors": [
    {
      "message": "Full permissions are required to use this endpoint.",
      "help": "For more information on API status codes and how to handle them, read the docs on errors: https://developers.asana.com/docs/errors"
    }
  ]
}

Our team is actively working on expanding OAuth scope support, and I’ll make sure this use case is noted.

  • Is there an alternative API endpoint to distinguish between licensed and guest users?

At the moment, the Workspace Memberships API is the only endpoint that provides this information, so we recommend using it for this use case.

As an alternative, the SCIM API can also expose some related fields that are visible in the Admin Console, though coverage is more limited.

  • Admin Console shows “Licensing Division” - is this field accessible via API?

Currently, the API does not expose division-level data, so this field isn’t retrievable via the API.

Hope this helps clarify things!

Best,
Dominik

Hello @Phil_Seeman @dbrdak !

Thank you for your answers and desire to help me understand the situation!

I made some changes and am now using PAT. It allowed me to obtain the values:

user_gid, user_name, user_email, membership_gid, is_active, is_admin, is_guest, created_at, workspace_name

“{baseUrl}/workspaces/{workspace_gid}/workspace_memberships?opt_fields=gid,created_at,is_active,is_admin,is_guest,user.gid,user.name,user.email,workspace.name”

The values ​​in user_gid and membership_gid are unique for each users.

All people have value the field is_active as true

Some people have the correct value of field is_guest as false or true

But this still isn’t enough to understand who we’re paying for and who we’re not. Because I get a list of 182 people through the API, but in the UI admin panel, I see that we only have 27 licensed users. Do you have any other ideas on how I can get a list of those we’ve assigned a license to through the API?

It’s not clear from your description what the issue is; specifically why you can’t use is_guest. How many of the records have is_guest = false? It should be 27?

Unfortunately, no. If I sort all the people with True in the is_guest field, I’ll get 10 people. Moreover, not all of these 10 people have an assigned license in our organization. Even the is_admin field doesn’t return all the correct values; True is only displayed next to my account, even though several other people in our organization have the Admin role.

Hi @Michael_Lysik,

Would you mind submitting this as a support case through our Help Center? We’ll need a bit more information to investigate why the is_guest and is_admin fields appear to be incorrect for some users, and a dedicated support case will allow us to dig into this properly.

Regarding the member counts: unfortunately, it’s not currently possible to get a 100% match with what you see in the Admin Console. One key reason is that the Admin Console’s Members tab does not include users in a pending invite state, while the API does. The team is aware of this discrepancy and while there’s no specific timeline I can share at the moment, I’ll make sure your feedback is recorded so they’re aware of the growing interest in aligning workspace membership data between the API and the Admin Console.

Thanks,
Dominik

1 Like