How to obtain shared folder metadata after calling endpoint /2/sharing/share_folder

[1575475]

Hi everybody,

yesterday our Team Dropbox has been converted to shared team space.

Now our API (REST calls via HTTP) we've developed during the last months is completely broken since we cannot create team folders anymore.

Documentation says we've to use shared folders instead.

So question is:

After calling above endpoint we receive a job id and no metadata.

After the job is completed 

/2/sharing/check_job_status

we need to fetch the metadata of the shared folder.

So far, nothing is working.

Calling the endpoint again results in an error (folder is already shared or so).

The endpoint 

/2/sharing/get_folder_metadata

needs an ID but we've only the path at this time.

Please elaborate.

Thanks in advance.

Best,

Jan

[Здравко]

---

@1575475 wrote:

...

The endpoint 

/2/sharing/get_folder_metadata

needs an ID but we've only the path at this time.

...

---

Hi @1575475,

In such a case calling /2/files/get_metadata will let you know you shared folder ID (sharing_info.shared_folder_id) and... you can continue from now on, I believe. 😉

Good luck.

[1575475]

Hi Здравко,

thank you. In the mean time I already was evaluating this endpoint, but unfortunately another problem occurred: No job is running (even after polling for about 10 Minutes or so), job id - of course - is present.

Setting for /2/sharing/share_folder: "force_async":false

Any suggestions?

Thank you and best regards,

Jan

[Здравко]

---

@1575475 wrote:

... No job is running (even after polling for about 10 Minutes or so), job id - of course - is present.

Setting for /2/sharing/share_folder: "force_async":false

...

---

I'm not aware of any explicit time limits. 🤔 For sure 10 mins should be enough. You can force such a query to be async, but no opposite! Setting "force_async" to false (by the way the default value) will just not force it be async, but without guarantees for synchronous execution. You should always check is the execution synchronous or asynchronous (if not forced) and when asynchronous, wait for complete or error. You should poll using /2/sharing/check_job_status; what does it return?

[Greg-DB]

@1575475 First, for information on interacting with a team space using the API, I recommend reading the Team Files Guide, if you haven't already.

If you want to create a folder inside the team space, you can use /2/files/create_folder_v2 with the 'Dropbox-API-Path-Root' header set to the team space. See the guide above for information on using that header.

If/when you use /2/sharing/share_folder to create a shared folder and get back an 'async_job_id', you should use /2/sharing/check_share_job_status (not /2/sharing/check_job_status) to check the result of the share job and receive the resulting metadata when it's complete.

[1575475]

Hi Greg,

many thanks. Yes, switching to the /2/sharing/check_share_job_status endpoint did the trick and I already see some silver lining 😃

I've another question regarding access inheritance.

Our scenario will look like this:

We'll have multiple apps where each app will be bound to a corresponding shared folder inside our new team space (as virtual root).

Each app will be operated by different users, so it would make sense not to inherit the team space to these folders, won't it?

Will adding users to a shared folder work as before when using the team folder api (creating a group, add this group to the folder, adding users to the group)?

Thanks again and best regards,

Jan

[Greg-DB · Accepted solution]

@1575475 Yes, it sounds like non-inheritance would make sense in that case, and yes you can make folders in the team space, and make groups, permit groups to folders, and add members to groups.