​@muthu Thanks for raising this!

You're right - the List Folder User Collaborators and List Document User Collaborators endpoints return individual users but not groups. For folders, you can use the List Folder Group Collaborators endpoint to get all groups with direct access.

Group collaborators on documents aren’t currently supported via API. We’ve noted this as a valuable gap and are discussing internally how to improve coverage between folder and document sharing. If we add support, we’ll follow up here.

In the meantime, if a document inherits access from a folder, you may be able to infer group access that way. Happy to help if you'd like guidance on that!

Hi ​@Richard Udell, Thank you for your response. Yes, the group id can be retrieved with /folders/<folder id>/shares/groups endpoint, but to get the name of the Group I believe we have to use SCIM API, which I currently don’t have access to. Is there a reason, why Group is not supported in REST API? 

I noticed another issue with REST API to retrieve the complete list of team folders. It only returns partial list though I’ve pagination and using the next page url returned on the “next” header. 

The reason I’m using the API is because there seems no way to export the folder and document hierarchy along with the users and groups assigned to them. Is this export functionality available?

You have stumbled upon a unfortunate reality with the current state of our API and documents/users/groups/teams/etc. As the company has been growing, we have iterated quickly and repeatedly on the best way to expose and organize documents, folders, users, and groups of things, while maintaining our very high security standards. Because of this, we have gotten ourselves into a bit of a paradox. Do we wait until everything is settled and no more iteration is expected before building any endpoints for these concepts, or do we make endpoints as we go and try to fit them together as we evolve?  We initially tried the latter, but over time came to believe that there is no way a user could piece this miss-mash together anyway.

That is what you are experiencing with the group endpoints. Our concept of a `group` has been evolving and slowly turning into what we now offer as `teams`. (another concept with a confusing history).  SCIM is also effected by this fast changing concept, leading to even more confusion.

All that being said, we do not currently offer a “clean” way to get the basic information you are trying to build. It is spread across numerous endpoints, each of which may not be handling “groups” and “teams” intuitively. Its very unfortunate and a known issue which we are working to address, but its the long pole behind efforts to make all of this less confusing in the product first. I apologize for the situation it puts you in and sincerely hope we can get it all worked out sooner than later.

That being said, can you elaborate on which endpoint is not returning a complete list of team folders? I am guessing you are referring to https://developer.lucid.co/reference/listfoldercontents where the type is “team”.  I am not aware of any reason this “should” be failing, but can imagine some given the point made below. Is there anything about the teams that are not returning that is “different”? I know that’s broad and I’ll try to find a problem as well, but you would know your teams better than I and might see a pattern.

Hi ​@Michael B, Thank you so much for taking the time to explain in detail, really appreciate it. I can understand the pain of growing fast and trying to do it all. 

The listfoldercontents API link you provided needs a folder id. So, to get a list of folder ids at the top Team folder like the screeshot below, I had to use /folders/search with body of {"type": "team"}, then use those ids to call listfoldercontents. This search endpoint is what is returning partial list. Wonder if you have any filters on what it returns.

I found a work around to get the Group name by getting the group id from the /folders/<folder id>/shares/groups endpoint and manually creating key/value pairs of group id and name by inspecting the API calls of the Groups in the admin screen. 

Now I’ve the report I need but not complete due to partial list from search API. It’ll be great, if you can let me know how to get the search API to return complete list.

Thanks again ​@Michael B for your efforts to help me.

Thanks Muthu. I will do some research and try to find a cause and we can go from there. I expect that it will be some scenario where our endpoint is not properly accounting for how you got added, or can see them, or etc. This screenshot helps a lot because it allows me to tell which `teams` we are talking about. Lucid has used the terms a few different ways, leading to much confusion.

Following up, I have not been able to find an explanation for the discrepancy that you are seeing with the folder search response. However, I still have a few paths of investigation.  Let me know if you see anything that might suggest a pattern of which teams are not included.