generation of preview for business user

[akirapix]

Hello,

i developed an integration for our applications that allows user to create a sharing link using dropbox api method "sharingCreateSharedLink".

I tested it using some personal account and had no problem, but it does not work with a business account of a colleague.

this method takes two params: short_url and path

short_url is always false and path is the relative path of the file i want a preview for.

If a file resides in /Users/<user>/Dropbox/path1/path2/path3/file.pdf then "path" parameter will be "/path1/path2/path3/file.pdf"

I noticed, on this business account, that relative path on Dropbox is little different. Instead of being "/path1/path2/path3/file.pdf" is

"<user_name>/path1/path2/path3/file.pdf". 

I tried "sharingCreateSharedLink" passing as "path" parameter both "/path1/path2/path3/file.pdf" and "<user_name>/path1/path2/path3/file.pdf" but dropbox replies always with "path not found"

is there any difference between personal and business account i should be aware of?

thanks

[Здравко]

There are some differences. The devil is always in details. Did you follow: https://developers.dropbox.com/dbx-team-files-guide?

Key moment is the difference between user home and account root! In some accounts (including all individual) they are the same thing, but that's not for all team account (in most cases they are different things).

Hope this gives direction.

[Greg-DB]

@akirapix Yes, as Здравко said, business accounts can be different; they may have a "team space". By default, API calls to the Dropbox API operate in the "member folder" of the connected account, not the "team space". That means that by default, the contents of the team space will not be found.

You can configure API calls to operate in the "team space" instead though, in order to interact with files/folders in the team space. To do so, you'll need to set the "Dropbox-API-Path-Root" header. You can find information on how to use this in the Team Files Guide.

By the way, sharingCreateSharedLink is deprecated in favor of sharingCreateSharedLinkWithSettings, so please use sharingCreateSharedLinkWithSettings if possible.

[Здравко]

---

@Greg-DB wrote:

...

By the way, sharingCreateSharedLink is deprecated in favor of sharingCreateSharedLinkWithSettings, so please use sharingCreateSharedLinkWithSettings if possible.

---

It's mentioned already multiple times by different users here on the forum, but let me recall again. When somebody needs a link to be received and it doesn't need to be new one, using sharingCreateSharedLinkWithSettings is pretty inconvenient. For existing link, it throws an error, that may contain the existing link, but that's not guaranteed. So for simple task to just get a link, developer will need to implement logic chain that may leads to second API call (sharingListSharedLinks) - something meaningless on my opinion too. This could be resolved as single boolean flag addition on top args level - let's say named "only_new_link" that is optional and defaults to true - the current behavior, so everything would be full back-compatible without affecting existing SDKs. 😉

I believe that in most cases, developers will set this flag to false, so a typical code (for typical use case) will be much simpler (and usually faster - not only possible, but guaranteed single API call for a link). Also, no need valid link to be received like an error as is now - much simpler code and easier error handling (real errors only).

[Greg-DB]

@Здравко Thanks for the feedback and suggestion! I'll pass it along to the team.