In April, 2026 pCloud removed the ability to use username/password authentication from their API. They also revoked all auth tokens previously granted by this method.
I only found out when the playlist application I’d written stopped working. That this change was permanent was confirmed in a response to an email to pCloud support. That response also told me I’d have to use OAUTH2 authentication for the playlist application.
This flow is documented on the developer portal. To use it, one must have an 'app' defined in the developer account. Such apps cannot be created by end users, but only through a request to pCloud support. Once the app is created (you can call it what you like), you are provided with a Client ID and a Client secret, which are used in the OAUTH2 protocol flow.
I rewrote the underlying pcloudapi.py module to use OAUTH2. In
short, it’s a pain. It involves a browser (so awkward for headless
use), and calling the pCloud endpoint through a third-party website to
protect the Client secret.
This flow worked; I had an access_token. However, the access_token
didn’t seem to work with the API calls that the playlist app used
(handling collections): the calls gave login required error
messages. After much to-ing and fro-ing with pCloud support, I was
told that this was deliberate. The access_token will only work with
API calls related to files, folders and maybe some others I hadn’t
used. This made sense, as rclone had continued to function normally
against pCloud.
To confirm this, I wrote some python code to copy files to and from pCloud. The access token does work with this mode of usage.
It’s disappointing that I can no longer automatically update the pCloud playlists to reflect music added to my collection. It’s also not good that the pCloud API documentation has not been updated to reflect reality.
