Support

There are three fine points.

When you ask Dropbox to share a file it creates a URL that ends in ?dl=0 This means that a page will be displayed where a browser can download that file. Using that URL with Kickstart will not work. You need to replace ?dl=0 with ?dl=1. Due to the way Dropbox works, if you use the dl=0 URL it tells us that the download was successful and that there's more data to follow. This is what is causing the infinite loop you experienced. We can't work around that as the "fix" would actually break HTTP downloads from well behaving servers (the majority of server) :/

The file sharing URLs do not have a 1:1 mapping with filenames. That is, we can't just replace .jpa with .j01 in the URL you provided and try to import that part file automatically. You will need to manually import each and every part of your backup archive.

Kickstart uses the base name of the URL to download the file when using Import from URL. As a result your imported files will be in the form of actual_file_name.jpa?dl=1 which makes them unusable for archive extraction. Therefore, before extraction, you need to go through FTP or the file manager in your hosting control panel and rename these files so that the all have the same name and the correct extension (.jpa, .j01, ...).

I'd like to note that I explored the possibility of adding Dropbox support to Kickstart itself. Unfortunately, this required us hosting a special server to act as the authentication gateway, just like we do with Akeeba Backup. The difference is that Akeeba Backup saves the token so it really needs to access our server very infrequently. Since Kickstart does not have any storage (obviously) it would have to make several requests to our server during import. That would disrupt the service for Akeeba Backup. Therefore we decided to not add direct integration with Dropbox or any other service using OAuth2-based authentication such as Google Drive and OneDrive. We recommend that you download the files locally and upload them to your server or, if your Internet connection is really slow, that you use the import from URL feature taking into account the three fine points above.

It would be important to know if the other cloud services present the same scenario of having to rename files.

This depends entirely on the share URL they create. Since the share URLs always have a query parameter suffix it's generally true that share URLs require renaming.

This also means I'm looking for a processing engine on your list that will allow me to restore a backup or transfer archives independent of having to manage the files via SFTP after the import.

Store the on Amazon S3 and use Akeeba Kickstart Professional. Kickstart Pro has an Amazon S3 integration. You just select the backup archive from your Amazon bucket and it imports all parts automatically. S3 has all the right API tools to make that possible. I love S3. It's the best thing since sliced bread!

Would the Rackspace option require one to change filenames after an import?

Yes. RackSpace CloudFiles' signed URLs fall in the same category I described above.

In the least desirable scenario, would the remote SFTP server option require one to change filenames after an import?

No. The uploaded files already have the correct file names and extensions.