Long story short, Confiks takes Spotify to task for removing the API that SongKick used to retrieve playlist data; a short time and several factual emails later they restore API access.
To summarize, Spotify can of course terminate any API they so wish, and there is absolutely nothing in GDPR that compels them to keep it up. As long as they of course still follow the requirements by GDPR. As annoying as a workaround would be for Confiks, emailing the data within those 30 days to SongShift is acceptable and in compliance. There is nothing in GDPR that says "data transfer options once enabled cannot be removed and/or changed".
Quoting the clause "the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible.", always seemed off with what is being demanded, because, they would be complying with that requirement by compiling and archive of the data, a big dump, and send it to SongShift. "I demand that you re-enable the API", on the other hand has no basis whatsoever in GDPR. The quote follows with "... or allow for some other method to allow me to exercise my rights under the GDPR", which is exactly right.
Spotify re-enabled the API because they chose to, not because they had to.
To clarify: I think it was great that Confiks convinced Spotify to re-enable the API. But, the arguments presented were not particularly convincing, and I took this as a case of Spotify doing the right thing, rather than a "David vs Goliath".
Spotify re-enabled the API because:
• they already had the API, so they couldn't claim it was an undue development burden to re-enable it;
• it was cheaper than setting up another system based on manually emailing large chunks of the database; and
• it was good press.
Regarding the second bullet point, you would have to explain to me what that has to do with GDPR.
To get back to the original point, activating this API is suggested as the clear winning example of GDPR. And, the counter argument I provided is that Spotify could have chosen to not activated the API, and still be in full compliance of GDPR. However, they evaluated the situation, and decided to activate the API.
I'm not making a point beyond this, so the responses so far have been a bit confusing. Yes, GDPR was part of the factors that pushed in the direction of enabling the API, and this is a good thing. However, the argument is only that GPDR did not compel them to do so.
Without the gdpr the cheapest alternative is to dev null the email, with the gdpr the cheapest alternative is to re-enable the api.
> I'm not making a point beyond this, so the responses so far have been a bit confusing.
Welcome to the internet :P
I do think your point is a bit weak here to be honest, and that people are reacting to this. It relies on interpreting the original demand as strictly "re-enable the api" and not "comply with the GDPR, and btw we both know the easiest way for you to do that is to re-enable the api".
In the example being used it was really the latter, consider that all the followup emails included the phrase "or allow for some other method to allow me to exercise my rights under the GDPR". It's also not like the overall goal of exporting data to another provider would have not been achieved if they implemented some new method instead, you can be sure that songshift would still do the work to make it easy to switch from spotify to them.
> the data within those 30 days
This is a common misconception. The requirement is
> GDPR information must be provided without undue delay but at latest within one month. Only in reasoned cases may this one-month deadline be exceptionally exceeded.
The operative requirement is without undue delay, one month is a maximum on the definition of undue delay, not a minimum. Intentionally delaying compliance for the better part of a month after you have demonstrated the ability to send the data within seconds would undoubtedly constitute undue delay... (Some exceptions apply)
Breach of this is not easy to prove, and I think that if this was to reach the court, it would be easily be dismissed if the user had their data transferred (in any form that can be processed, and not necessarily whatever was part of the original API spec) within 30 days.
Proving that undue delay was caused, is a much higher bar to meet. Again, less high due to the correspondence in question.