nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Error handling with /2/members/get_info and /2/team/groups/members/list

AEmery

Hi,

Two distinct problems, but since they are similar, I figured I'd group them in the same post here.

/2/members/get_info

If I supply a member id that doesn't exist this way:

{
"members": [
{
".tag": "team_member_id",
"team_member_id": "dbmid:someUserId"
}
]
}

I get a 200, with ".tag": "id_not_found". Shouldn't it be a 409? API v1 used to reply with a 404.

/2/team/groups/members/list

If I supply a group id that doesn't exist, I will either get a 200 with an empty "members" list, a 500 with an empty body or a 409 with ".tag": "group_not_found" depending on the invalid id I send.

Am I right in expecting that these should all be 409s? As above, API v1 used to reply with a 404 for all of these cases.

Thanks for clarifying these points.

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

The 500 should also be fixed now. Please let us know if you're still seeing any issues.

All comments

Greg-DB

Thanks for writing this up!

For /2/team/members/get_info, this is the expected behavior. A successful call will return a list of MembersGetInfoItem, where each one is either id_not_found or member_info. Since this endpoint can accept multiple UserSelectorArg, the call itself will return an overall success with an id_not_found or member_info MembersGetInfoItem per input UserSelectorArg, so that it doesn't need to fail the entire call if just some of the input UserSelectorArg are not found.

For /2/team/groups/members/list, the expected behavior is the 409 with group_not_found. The 500 is a bug that I can reproduce, so we'll look into that. The 200 with an empty "members" list also isn't expected, but I can't reproduce that. Can you share a sample group ID value that gives you that? Thanks in advance!

AEmery

Yeah sure, here's more details:

The Dropbox Business environment that we use for tests purposes has 3 groups as shown in the admin console or via the /2/team/groups/list API call.

One of these groups has "group_id": "g:57460cd2e2edd1cd000000000000001a". If I call /2/team/groups/members/list on this group id I get, as expected, a 200 with the members listed under the "members" token in the response body.

If instead, I use g:57460cd2e2edd1cd000000000000001b (which is not one of my three groups), I get this response:

Status 200 OK

{
"members": [],
"cursor": "someCursor",
"has_more": false
}

In fact, I can change pretty much anything in last 16 characters of the group id and I get the same empty "members" list.

Hope this helps

Greg-DB

Thank you! That's helpful. We'll look into that too.

Greg-DB

The issue of the incorrect 200 response with an empty members array should be fixed now. The issue of the 500 response is still being worked on, and should be fixed soon.

Greg-DB

The 500 should also be fixed now. Please let us know if you're still seeing any issues.

AEmery

Hello Greg,

Just tested this and indeed I get a 409 every time, thanks for that. Strangely though, the body of the response is:

{
  "error": "No matching groups found for g:57460cd2e2edd1cd00000000000001b."
}

{
  "error": "Some groups are not on the team."
}

Shouldn't it be in your standard format as specified in the APIv2 documentation?

{
"error_summary": "to/no_write_permission/..",
"error": {
".tag": "to",
"to": {
".tag": "no_write_permission"
}
}
}

Thanks for your input.

Greg-DB

Yes, a normal structured error is expected for these API v2 endpoints we were discussing.

It looks like you may be calling API v1 though (i.e., /1/team), based on the error messages you shared. Can you check if that's the case?

AEmery

Yep, you are right. My bad...