I’m working on a music app that shows several Spotify playlists on one screen. When someone starts playing a playlist, I want to highlight the follow button for that specific playlist. I can already get the current song using the player API. But I can’t figure out how to get the playlist info. Is there a way to find out which playlist is currently active? I’ve been looking through the documentation but haven’t found a clear solution. Here’s what I’m trying to do:
function getCurrentPlaylist() {
// Get active track - this works
const activeTrack = playerAPI.getCurrentTrack();
// Need to get the playlist for this track
const activePlaylist = ???;
return activePlaylist;
}
Different approach - don’t rely just on context since it’s unreliable. Use the Web API’s /me/player/currently-playing endpoint with additional_types set to include episodes and tracks. You’ll get much better data about what’s actually playing.
Here’s the key: store a timestamp whenever users hit your playlist buttons. When context fails or returns null, match the current track against your cached playlist data using track IDs instead of URIs.
This saved me when users played the same song that exists in multiple playlists - the interaction timestamp tells you which playlist they probably meant to play from.
Context breaks when people start playback from voice commands or third-party apps. I fixed this with a hybrid approach - track user interactions in my app, then fall back to comparing playlists when needed. I grab the current track’s metadata and see which playlist has that exact track at the same position. Not perfect since songs show up in multiple playlists, but adding timestamp tracking makes it pretty accurate. The Web API’s player endpoint gives way more consistent context data than the SDK, especially with collaborative or shared playlists.
The Web Playbook SDK’s getCurrentState() method is what you want. Call it and check track_window.current_track.context - that’s where you’ll find the playlist URIs and other source info. Just heads up though, context can be null sometimes when people play individual tracks or jump between sources quickly. I’ve hit issues where context doesn’t update right away after playlist changes, so you might need a small delay or polling to catch those cases. Also, if someone’s shuffling between multiple playlists or using radio, the context won’t always point to the playlist you expect.
Been wrestling with this for months too. The context method has serious issues with collaborative playlists and manual queuing. What worked for me was a hybrid approach - I track playlist interactions on the frontend and cross-reference with the Web API’s recently played endpoint. The recently played data gives you context info that’s usually more accurate than player state. Here’s what people aren’t mentioning: private session mode completely breaks context tracking, so you need fallback logic. Also, context updates can lag several seconds on slow connections, making real-time highlighting unreliable without local state management.
the context thing breaks when users hit play on a playlist then manually skip tracks or add stuff to the queue - it loses track fast. easier fix would be tracking which playlist button they clicked last and assuming that’s still active, unless the context shows something completely different.
yeah, spotify’s context object is tricky. here’s another gotcha - when users play from search results or recently played, the context might show something totally different than your playlist, even with identical songs. i always store the playlist id when someone hits play, then cross-check it against the context uri just to be safe.
context uri works most of the time, but podcast eps in playlists will totally break ur tracking. plus, if spotify connect switches devices mid-song, it can reset context to null. maybe add a retry mechanism or cache the last playlist state.
Context tracking breaks when users switch playlists on their phone or desktop while your web app runs. I’ve seen it show playlist A when the user actually switched to playlist B on mobile. I fixed this by polling the player state every few seconds to catch context changes. Heads up - Spotify Connect handoffs between devices completely reset context data, so you’ll need error handling for that. Web API endpoints work better than the SDK for this, but there’s always some delay between playlist changes and when your app picks them up.