Child Item

Dropbox Webhooks to get group changes notifications

I'm using the Dropbox Business API. I've been successful at experimenting for a while with webhooks for file changes and having an understanding of the documents getting uploaded/deleted from Dropbox from all the users.

Now I need to do the same but for user permissions. I need to understand given a list of users with access to Dropbox, what folders they can access, and ideally I want to do it using Dropbox webhooks. This business is set up in a way that users get access to the right folders by putting them into a Group.

So, I mainly have one question: can webhooks register and push a notification when there is change in a group? (i.e. an user has been added/deleted to/from a group)

When configuring the Dropbox app for the webhook, I've tried giving it all the permissions that seemed to make sense but I’m only getting notifications when a member has been added/deleted to a shared folder, and not when a group (with users in it) has got access to that particular folder, if it makes sense.

I would really appreciate if you could give us some insight here and provide any documentation that is not on the website (if there is any).

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Unfortunately Dropbox doesn't offer the ability to get webhook notifications for changes to groups, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.

andreavillares

Thank you for your quick reply.

Is there any other alternative that I could use?

I tried a similar approach using cursors and different methods such as

team_groups_list

team_groups_list_continue(cursor)

team_groups_members_list

team_groups_members_list_continue(cursor)

and I was expecting to obtain when calling the continue with the previous cursors, an empty list if there wasn't any changes in the groups or the members within a group but it doesn't seem to be working that way as it does with other methods such as

team_members_get_info

team_members_get_info_continue

however in team_members_get_info, I don't get new information when a member gets added to a group.

Does my problem make sense?

Greg-DB

I'm not sure I quite follow your latest post. Using team_groups_list and team_groups_list_continue is the right way to list the groups on a team, and using team_groups_members_list and team_groups_members_list_continue is the right way to list the members of a group, but "team_members_get_info_continue" isn't a Dropbox API method. Was that a typo?

Perhaps you could share the relevant code snippet(s) of what you have so far to help illustrate?

andreavillares

Hi, I'm referring to the following API endpoints:

/members/list

/members/list/continue

/groups/list

/groups/list/continue

/groups/members/list

/groups/members/list/continue

At the moment I can call /members/list to get a list of all the members within Dropbox Business, and if I call /members/list/continue with the latest cursors and hasn't been any changes, it returns with a new cursor and has_more false, so my code can interpret that if there are no members returned when calling /members/list/continue, there hasn't been any changes to the list of members.

However this is not the case when I call the other endpoints (that considering that it is based on a cursor, I was expecting similar behaviour). I.e. when I call /groups/members/list giving it a group id, it returns a list of the members of the group and a cursor. When I use that cursor to call /groups/members/list/continue, it returns the same list even if there hasn't been any changes.

And same happens when calling /groups/list and /groups/list/continue.

Does it make sense now? Thanks in advance!

PS: in my posts before I was referring to the Python SDK

Greg-DB

Thanks for following up and clarifying. The behavior of "use that cursor to call /groups/members/list/continue, it returns the same list even if there hasn't been any changes" doesn't sound like the expected behavior. It looks like that's a bug on these /2/team/groups/list/continue and /2/team/groups/members/list/continue endpoints. I'll ask the team to look into it and I'll follow up here once I have any updates to share.

andreavillares

Thank you Greg, this is almost a relief, as I wasn't sure if it was an issue with my understanding of the documentation.

I'll wait here for the answer 🙂

andreavillares

Regarding the previous API endpoints, I was trying to work my way around it by doing the following using python.

from dropbox import DropboxTeam

dbx_team_client = DropboxTeam(
 oauth2_refresh_token=config.dropbox_creds['TOKEN'],
 app_key=config.dropbox_creds['APP_KEY'],
 app_secret=config.dropbox_creds['SECRET_KEY']
)

user_id = 'dbmid:xxxx'
dbx_user_client = dbx_team_client.as_user(team_member_id=user_id)
user_folders =dbx_user_client.sharing_list_folders()

This is all in a Dropbox Business account, that's why I need to assume the user so I can call the API endpoint "/list_folder" to understand which folders the user has got access to.

And it returns the following

ListFoldersResult(cursor=NOT_SET, entries=[SharedFolderMetadata(...)])

I don't understand why it doesn't return a cursor (as specified in documentation). I was hoping to save the cursor for each user and call "/list_folder/continue" to look for changes to the list of folders each user can access.

Is there anything I'm missing here?

Greg-DB

For /2/sharing/list_folders[/continue], the 'cursor' in the response is an optional value and is only returned "if there are additional shared folders that have not been returned yet", so it will not be set if there are no more entries to return.

Unfortunately, it's not suitable for monitoring for such changes over time like you're looking for, but I'll pass this along as a feature request for support for that. I can't promise if or when that might be implemented though.

By the way, in my own testing of the bug on the /2/team/groups/list/continue and /2/team/groups/members/list/continue endpoints, I'm finding that it seems to be possible to work around the issue by setting the initial 'limit' parameter to a value lower than the number of entries to return. I can't guarantee that will currently or always work for you, but I'm mentioning it in case it's helpful in the meantime.