Memberships endpoint not working when providing user type member

English Forum Developers & API
1

When making a GET call to the /memberships endpoint, I am providing a user GID as the “member” query parameter and “project_membership” as the resource_subtype query parameter. According to the documentation, “parent” is not required when using member and resource_subtype together. I am leaving it out because my goal is to find all projects that the provided user is a member of.

However, when I make the call I get the following error (actual ID redacted):

{
    "errors": [
        {
            "message": "member: Not a recognized ID: XXXXXXXXXXXXXXXX",
            "help": "For more information on API status codes and how to handle them, read the docs on errors: https://developers.asana.com/docs/errors"
        }
    ]
}

I have verified that this is a GID for an Asana user who is a member of at least one project; if I instead make the same call but with one of his project GIDs as the “parent” query parameter (while leaving off member and resource_subtype), the call is successful and I see the user listed as a member of the project with the same user GID I am trying to pass in. Also note that team GIDs work correctly when passed in as the member parameter, it’s just user GIDs that produce this error.

Is there something I’m doing wrong?

2

I’ve only used the “blank parent and supply member and resource_subtype=project_membership” variant with a team GID and it worked properly as it did for you; I haven’t tried it with a user GID. But from the docs, it sure should work, so this sounds like a bug to me.

cc: @dbrdak @Mikhail_Melikhov

3

Hello @Grant_Hatchimonji and welcome to the forum!

What you’re seeing is not due to a mistake in your request, but rather a limitation that wasn’t clearly reflected in the documentation. I’ve updated the docs to better clarify the parameter constraints for the Get multiple memberships endpoint.

At the moment, requests without a parent parameter only support member values of type team. When a user GID is provided, the endpoint isn’t able to disambiguate the workspace context on its own, which is why it requires a parent to be specified in those cases.

I agree that this limits the endpoint for a common use case like “get all items a user is a member of”. I’ve raised this internally so the team can consider improvements here.

1 Like
4

This is very helpful information, thank you @Phil_Seeman and @Mikhail_Melikhov . If this functionality does get added at some point down the line, would it be possible to be notified here? Or is there somewhere I can sign up for API update notes?

5

@Grant_Hatchimonji this forum, specifically the Developers & API sub is the best place to stay up to date on API changes.