nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

Getting Share Link Before Upload Completes

edh

Hi,

Is it possible to add a file to dropbox and get the share link *before* the upload completes?

We're adding video files, which may take several minutes to upload, so having the user wait is a bit painful.

This seems to work fine on the desktop - if I drag a large file into a Dropbox folder, I can immediately get the "Copy Dropbox Link" (and if I use the link I just see a File Uploading page - which is fine for us), but I can't figure out a way to do this with the APIs.

Thanks for any thoughts.

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

No, I'm afraid I can't think of another workaround for this. Using the deprecated endpoint or using a placeholder file are the only things that come to mind.

The shared links can't be "computed" exactly, since the token in the URL is randomly generated only when the link is created.

All comments

Greg-DB

This is technically possible using the 'pending_upload' parameter on /2/sharing/create_shared_link, but that endpoint is deprecated.

There isn't currently a non-deprecated way of getting a shared link for a pending file like this, but I'll be sure to pass this along as a feature request.

edh

Hey Greg,

Thanks for the quick response.

Can you think of any other work-aounds for this? Would uploading a small (like 1 byte) file, getting the share link, then replacing it with the full video file (same file name) work?

thanks again

Greg-DB

That should technically work, but I don't recommend it, since it makes the process less obvious/more error prone. For instance, it may make it less obvious if the actual file upload failed, since the the file would appear to already be there as far as the user can see, if they don't check the file size. The user may then download the temporary file without realizing it isn't the real file.

edh

Thanks again, Greg.

Any other suggestions or workarounds you can think of for this?

Breaking up the user's workflow like this waiting for a download link is a non-starter for us. (and as a user myself, it's painful! ;-) )

Is there anyway to compute what the final share link will be, or anything elase we could try?

Thanks!

Greg-DB

Steve L.

What would be very helpful would be an atomic batchUploadFiles which created and returned share links for all of the URLs in the uploadFilesUrlsToCommitInfo dictionary (to use Obj-C terminology).

This would simplify sharing a batch of files, reducing both latency and the number of requests needed.

Consider this a feature request

Greg-DB

@Steve L. Thanks! I'll send that along.

Terryble

Would also love to see a solution to this.