I would like to switch from (paid for) Google Drive to (paid for) Proton Drive. But Insync for Linux doesn't support Proton Drive due to the lack of an API.

This might be even better for me than the other suggestion about syncing to Android, honestly.

PLZ GET UR SH!T 2GETHER SO I CAN START GIVING U MY MONEY.

As of right now, the usefulness of Proton Drive is rather limited. It is not really usable for an automated backup-- and judging from the posts from the devs/mods on other forums, using it for such a thing is frowned upon/discouraged... which is a pity. And even when the API is finally usable, it was implied that this will not change for the foreseeable future.

I would hope this stance changes and there will finally be first-class support for things like Rclone. Otherwise what is the point of having lots of cloud storage space in the first place!?

The JavaScript API for Proton Drive should not be restricted to a Node.js package. For greater flexibility, it should also be available as a standard ECMAScript module and as a non-ES JavaScript source file.

In addition to web apps, authors of browser extensions (for Chrome, Edge, Safari, etc.) would be interested in using Proton Drive as a storage back-end to enable synced data between the user's machines where their browser extension is installed. A JavaScript API would allow browser extension authors to give their users more options on which cloud file storage service they want to use.

i'd like the APi to be able to add/update/remove on Proton sheet.

From a user perspective, it is currently very difficult or no longer possible to use third‑party tools or automations to upload files directly into Proton Drive. I see that there is now an SDK available on GitHub, but at the moment it still feels very limited and not yet reliable or easy enough to use for everyday automation.

The main problem is the lack of a simple, stable way to programmatically upload files to Proton Drive. This makes it hard to replace other storage providers (MinIO/S3/Wasabi/etc.) with Proton in automated workflows such as:

“Scan to cloud” from a printer or scanner (e.g., Scan → directly to Proton Drive, instead of to S3 or another third party).
Small scripts or tools that regularly send files to Proton for safekeeping.
Workflow tools such as n8n, which could create or process something and then send the result straight to Proton Drive.
Server‑side automation like:
Scan to NFS → script uploads to Proton Drive
Database dumps / backups from servers → script uploads directly to Proton Drive
Fully digital/paperless household setups where everything from everywhere (documents, scans, exports, logs) is automatically funneled into Proton Drive as the central, secure storage.
Suggestion

Provide a documented, stable upload API (or significantly expand and stabilize the existing SDK) that:
Allows authenticated clients to upload files/folders to Proton Drive programmatically.
Handles the complex parts (encryption, key handling, etc.) so that users only need to integrate a simple library or CLI tool.
Ideally offer:
Official client libraries or SDKs in common languages (e.g., JS/TS, Python, Go, etc.), or
A secure CLI tool that can be used in scripts, Cron jobs, CI pipelines, home servers, and NAS devices.
This would allow users to send data directly to Proton’s secure storage without intermediate devices or untrusted third‑party services, which is exactly what many privacy‑conscious users are looking for.

I really need this for n8n automation. Otherwise, I will have to switch to a different provider (like Google Drive... yuck!)

Drive API is critical for backup utilities. I want to use Duplicati

Yes please. Make Proton Drive finally useful!

This is over four years old, can we get a response from Proton?

Same here. Critical feature for a cloud provider. I appreciate the security considerations, but this is needed badly.

An API would allow to properly integrate Proton Drive to backup solutions like Duplicati in order to run automated backups to a secure storage.
Until this is possible other commercial cloud storage vendors remain more viable for this use case.

Existing options using rclone create so many errors that my proton drive storage is totally useless to me (P.S. I don't do photos!)

We need this so bad...

Duplicati user here. I want to backup to you, not to Google Drive.

This should probably be moved to PLANNED or STARTED status (as appropriate), since it was announced in the November 2024 roadmap that Proton is building a Drive SDK.

Presently I'm giving this a "Critical" vote, due to the complete lack of a Drive app for Linux.

És molt bona idea; seria genial per poder implementar-ho en formularis web, utilitzant l'emmagatzematge a ProtonDrive per crear backends i bases de dades d'usuaris, etc... a un preu assequible. Aviam si en endavant podem comptar amb un "Proton Apps Script" !!!

Yes, please give us an API and authentication method we can use with open source tools like rclone

My basic need is to strictly manage identities. There is a crucial gap, in my opinion. I notice that to use Proton Drive (and ProtonVPN) securely, we need to be able to use an identity without having to share the main secret of our ProtonMail account. However, this seems unavoidable, as it is also the secret for ProtonDrive and ProtonVPN (using rclone and the 'obscure' directive is not enough to ensure sufficient protection). A solution would be for Proton to comply with OIDC/OAuth2, allowing us to use Proton Identities and Aliases in authentication and authorization protocols based on their own service infrastructures, i.e., without relying on external elements to enable integration that would then need to be verified and maintained with the associated secret management. We are aware that this business direction requires some investment and preparation to meet the demand that would certainly follow. But it seems already taken since a Business offer of Proton Drive is established. This offer cannot reasonably operate without these additional shared services, which are certainly already operating in your billable services. Your business model is indeed at stake, but you need to start by aligning these elements and responding to the community. It is clear that you face the same challenges of functional evolution with a highly visible security aspect, and we understand the required caution. Looking forward to your response.