cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
If you’ve changed your email address, now's the perfect time to update it on your Dropbox account and we’re here to help! Learn more here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

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

AEmery
Explorer | Level 3
Go to solution

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.

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution
The 500 should also be fixed now. Please let us know if you're still seeing any issues.

View solution in original post

8 Replies 8

Greg-DB
Dropbox Staff
Go to solution

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
Explorer | Level 3
Go to solution

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
Dropbox Staff
Go to solution
Thank you! That's helpful. We'll look into that too.

Greg-DB
Dropbox Staff
Go to solution
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
Dropbox Staff
Go to solution
The 500 should also be fixed now. Please let us know if you're still seeing any issues.

AEmery
Explorer | Level 3
Go to solution

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."
}

 

 

or 

 

 

{
  "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
Dropbox Staff
Go to solution
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
Explorer | Level 3
Go to solution

Yep, you are right. My bad...

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    AEmery Explorer | Level 3
  • User avatar
    Greg-DB Dropbox Staff
What do Dropbox user levels mean?