Access to websockets

[EricRabil1]

Hi, I'm re-opening an issue that has been closed (#817), ignored (#1330, #538), or locked (#492) time and again.

While I'm very thankful for the APIs Spotify provides developers, the lack of transparency/availability regarding the WebSocket APIs is making this a frustrating platform to develop for. This is further exacerbated when one reads through issues that are over a year old, saying that Spotify is still working on bringing public WebSocket APIs to third-party clients.

Additionally, though I will not go into detail, Spotify literally has WebSocket APIs that it uses for its web client. Why can't these APIs be made available to third-party users? They seem pretty data-rich to me, and stable enough to be deployed to your production software.

Moreover, I plead that the developers respond openly to this, whether WebSockets are coming or not, and not something opaque such as "the more time we spend on making sure people aren’t ‘investigating’ non-public APIs that they’re not authorised to access, the less time we can spend on making these APIs ready to be available to the public" (#817). This is not only unhelpful, but a childish response to a valid request. It was valid in 2018, and frankly, is even more valid in 2020.

Please, please release a public WebSocket API. Polling the API every few seconds is disgusting, wasteful for your servers and ours, and rate-limit prone.

x-post from https://github.com/spotify/web-api/issues/1558

[BagJason]

Seconded!

Not only are there countless people behind me who want this feature, I need it because I'm writing an app to control a dancing robot (Google: My Keepon) and that needs realtime information of playback (so it dances in time to the music*).

What I don't wanna do is repeatedly hammer the Spotify /v1/me/player/currently-playing endpoint every 1000 ms and compare changes between each request before then hitting /v1/audio-analysis/{id} to get "dance" data, only to then be out of sync.

I would dearly love a Spotify WebSocket that can just tell me the track / playback status has changed and this would save both mine and Spotify's resources all round.

* For anyone who cares, this is the robot in question, and yes, I love my RGB; https://www.dropbox.com/s/pp17jen51rqe2hb/2020-05-12%2013.54.17.mp4?dl=0 

[CodingKiwi]

I could not have put this in better words.

We feel ignored and stranded with this lack of transparency, and as EricRabil1 already wrote:

Polling the API every few seconds is disgusting, wasteful for your servers and ours, and rate-limit prone.

Personal opinion / guess:

I think spotify has no reason to provide public websockets other than saving server resources (also one would have to investigate if websockets would cause more network traffic and therefore problems).

Allowing developers to build awesome realtime projects is not good for them because someone could then build a ad-free spotify-client clone which would lead users away from their own client.

I understand that, and I would be perfectly fine if someone from spotify would finally admit that we wont get websockets because they would lose money or something, but they just stay silent.

This just hurts the image of spotify as my personal opinion now is "If spotify cant make even more money out of a feature they dont care."

Another option would be offering partnership deals, paying money to be able to use the websockets in a way spotify is fine with. For example discord, there the websockets are used only to display the current track and time.

I feel like nothing I try to program with spotify is worth the effort

[dinospot]

Track/Playback status changes near realtime is needed for a genuine use of the Spotify web api.

It's conceptually wrong imho to require applications to continuously poll the api to get those vital informations. Without this we create slow response applications (with very bad user experience), high api requests/second falling to high ratelimited requests (with very bad user experience) and probably high load server side (both consumer and spotify).

I think that creating a callback api with auto retry (eg I really really love the callback api implemented by telegram bots) can increase the spotify app ecosystem a lot.

Thank you!!

[CodingKiwi]

Yes, webhooks or callbacks would be another awesome thing, it would not require a constantly open TCP connection but instead only small-payload GET/POST requests to an endpoint on consumer side that indicates track and/or playback changes

[dinospot]

I really don't think that playback status change notification via callback api is sufficient to implement a spotify client clone with no ads... Why do you think so?

[EricRabil1]

@CodingKiwi I see where you're coming from, though I would argue that @dinospot has a fair counterclaim that I'd like to build on.

Given Discord presences are realtime, you could theoretically build an API that pulls the Spotify presence from your Discord presence and you'd have a lot of metadata right there. But you'd be missing some key information, like the track ID.

Because this data is still freely available to Discord developers in realtime, it doesn't make much sense for Spotify to not provide similar functionality through their own APIs.

[BagJason]

I concur, having a playback status change websocket doesn't circumvent subscription level.

[spotifyjosh]

@BagJason, that robot is impressive 🙂

@EricRabil1 @dinospot @CodingKiwi Thank you for letting us know that this is something you'd like to see. I will be sure to share your feedback with other folks on the team.

[BagJason]

@spotifyjosh Thank you bud, we look forward to hearing from them.
It makes sense really, it will actually _reduce_ load on the Spotify API servers and at least 90% of the code should be there from the Spotify Web Player 🙂

[brennanerbz]

How does Discord solve this?

[BagJason]

Heya @spotifyjosh

Is there any further news on this request please? 🙂

[EricRabil1]

Spotify connects to Discord using Discord's RPC protocol.

[Matthew-S]

When I first read through the API I thought I was missing something because I couldn't find what I assumed to be an obvious endpoint for a music streaming platform. I think it would be smart to assume this will be an infinitely de-prioritized issue and the Web API will remain something cool for small "toy projects".

While I think it sucks that no progress has been made on this, I think the larger problem is the veiled curtain that exists between internal development and the public. I'm assuming it's a cultural problem with the company though that any individual developer probably couldn't solve. In an ideal world we would hear answers like "A developer on our team tried to get this to working last week but it ended up requiring massive architectural changes that wouldn't be feasible right now. We are planning to release a new version of our API in a few years that should support this". Or maybe "Unfortunately, we believe this is a feature that we would like to monetize for corporate partners. If you would like to partner with us for this feature please contact our sales team."

Anyways, I think I'm crazy for imagining they would ever say something like that even in an alternate universe xD.

[BagJason]

Hi all, I have raised this as a new idea - please vote for it here;

https://community.spotify.com/t5/Idea-Submissions/Developer-Access-to-websockets-for-live-playback-i...

[jcwoiwoi]

As everybody said, we're stuck with unadapted technologies.

Polling is not eco-friendly, nor efficient and subject to rate-limiting (that's fair, though).

But please provide us a way to access an already-existing and stable API. Discord has a dev-friendly system and you can interact with the app really easily thanks to their APIs. Now it's your turn, become dev friendly and the de-facto standard for building apps revolving around music.

[EricRabil1]

@SpotifyJosh hi king of the Spotify community – do you have any update on this topic? ❤️

[busybox]

Hey,

Any updates about this?
My app really needs it and fetching the API every second is very heavy.

Thanks again for your time and good luck implementing this!

[TheNoim]

Oh come on. This seems to be something requested for years now.

[EricRabil1]

Unfortunately, it seems that Spotify prefers to license out their WebSocket APIs to companies that are willing to pay (Discord!!) rather than expand on what independent developers can create with realtime data. No amount of reassurance can convince me otherwise at this point.

They've been quite hostile towards those that discuss the existing WebSocket APIs in the past. Their statement regarding the use of private APIs delaying the release of public ones goes to show this is not even on their radar.

From shoving us onto this god-awful community board to underwriting valid issues, Spotify shows little interest in helping out the little guys.