Help Wizard

Step 1



Please see below the most popular frequently asked questions.

Loading article...

Loading faqs...


Ongoing Issues

Please see below the current ongoing issues which are under investigation.

Loading issue...

Loading ongoing issues...


Positions field in JSON body is ignored when removing tracks from a playlist

Positions field in JSON body is ignored when removing tracks from a playlist

The Remove Playlist Items endpoint on has dropped its support for the positions parameter, which was supported previously and let tools like Spotify Dedup ( delete specific duplicates of a track and not all appearances of the track with that same id.


A comment in the snapshot field still mentions the previous "positions" field:

The playlist's snapshot ID against which you want to make the changes. The API will validate that the specified items exist and in the specified positions and make the changes, even if more recent changes have been made to the playlist.

20 Replies

I have the same problem. This parameter was important. Now that it is gone, you would have to remove all duplicated tracks and then add only one back, which is more complicated for developers and just results in more requests to the API. Also, the "Added" date of a song in the playlist is lost. This change is bad for developers, users of their applications, and Spotify itself.

ignoring the position parameter from the web api delete /playlists/{playlist_id}/tracks is a major issue for   users want to be able to delete a specific duplicate based on position.  now that position is being ignored multiple instances of the same track are being removed.  this breaks 


i am really hoping that the position parameter is supported once again.


this breaks spotipy.  this spotipy api is no longer working because position is being ignored:

- playlist_remove_specific_occurrences_of_items(playlist_id, items, snapshot_id=None)

this spotipy api calls the spotify web api: delete /playlists/{playlist_id}/tracks

The content logic for the snapshot_id has recently changed and makes version comparisons more difficult.


snapshot_id string
The playlist's snapshot ID against which you want to make the changes. The API will validate that the specified items exist and in the specified positions and make the changes, even if more recent changes have been made to the playlist.



Before, the snapshot_id was a Base64 encoded date. Now it is unclear.


Does anyone know the logic for the new snapshot_id?

I would appreciate a definition or logic.

I tried passing snapshot_id and the positions field, but positions was ignored. It seems that the mention they have on the developer site about the options field is a leftover from the previous version.

i finally managed to implement a workaround on Spotify Dedup which now removes all tracks with a specific id, and adds the track back at a position that is calculated based on the original position of the track to be kept and the shifts from the removed items.


Not the best solution, but given the zero response I’m getting from Spotify Platform I think it’s alright. 


In case someone else is having the same issue, it’s possible to remove tracks from a playlist specifying only the list of positions.


This is not optimal, since it can happen that the playlist contents have changed and you end up deleting the wrong track, or that you mess it up and remove the wrong index. Ideally, one would specify track id and position, but that doesn’t seem to be supported anymore.


This is the least bad alternative to remove duplicates, which I have just implemented on Spotify Dedup, in case you want to check it out (it’s open source).


I hope this helps other people having similar problems.

Here is an effort to clearly summarize the impact of this change:


Prior to this Spotify Change

If you have Multiple Copies of the Same Track in a playlist and you selected ONE of them to be removed, just the selected track would be removed.


After this Spotify Change

If you have Multiple Copies of the Same Track in a playlist and you selected ONE of them to be removed, now ALL copies of the selected track will be removed from the playlist.


If you have two copies of the same track in a playlist you can no longer remove just one of them, both copies of the track will be removed.  It is no longer possible to remove duplicates from a playlist using the web api.  All you can do is remove all copies of a track from a playlist.


Spotify Web API Documentation

I sure hope the Spotify Remove Playlist Items doc page gets updated to make this clear.

@ jperez  - thanks for sharing your very clever position work around!

This is beyond infuriating. Why break the api and communicate absolutely nothing? AGAIN? I'm sick and tired of this 😭 wth Spotify.


The best part is that I only found out about this because I stumbled upon this thread. I don't know how long it's been broken and there's no way for me to track down all the tracks that have been fully deleted from my playlists.


I don't understand why they dedicate time to randomly breaking the api and removing functionality every month. When was the last time anything new was added? Or improved? Why not just leave it alone if all they ever do is mess it up? What are they trying to achieve? 

as best i can tell from my server logs the delete /playlists/{playlist_id}/track api was broken around 2024/04/23.

Thanks slipstream422. My playlists are pretty borked now I don't know how I'll figure out which songs are missing. Spotify: the only music streaming platform that strives to make itself as frustrating as possible to use for users, artists, customers, contributors and API developers alike. 

you might considering asking spotify support to restore you playlists to an early date, i have not tried to do this but i heard someone else mention that they were in the process of doing this.

At this point I feel like just giving up my whole project that I've worked on all year. By the time they look at my quota extension request they'll probably have broken every endpoint I use anyway so it's a waste of time.

Spotify, please fix this bug!!

jperez - what is the formatting to remove by position?  I think I found the line in your program, but I don't know js so I can't really read it.  My program just removes the first song when I add a new one to the end, so this actually makes mine a bit simpler. 

I would caution against implementing the solution suggested by jperez in the long term - while it may work now, it's not documented in Spotify API and they will probably remove that functionality as well, randomly without warning, again.

Why is there no reply from Spotify saying when this will be fixed?

@bosi there never is. 

Using the web player, you can delete individual tracks, so I've been poking around in it and found a way to make it work. 


The web player deletes the track by sending the "uids" of the track, rather than the "uri" that we're used to sending with a location value.  If you make a playlist with a bunch of copies of the same song, they all have the same "uri", but have different "uids" values. 


To get the "uids" for a track, you need to send a GET request to to get the playlist data, then send a POST request to delete the track once you extract the "uids" from the previous response. 


The problem I ran into is that requires an extra token that I'm not sure how to get, called "client-token".  The web player gets it by sending a GET request to, but when I send a request to the same site that the web player uses to get it, I receive a much shorter code that doesn't work.  I assume it's because I'm not sending my information with the request and I'm getting some sort of guest login, but I don't know how to send that in the request.  I just copied the string from firefox and copied into my code.  It's been working for 3 days now in my app, we'll see how long it lasts. 


Also, both requests require you to send a Sha256Hash, but I don't know what I'm supposed to be hashing and sending.  However, this doesn't seem to matter because I'm just sending a random hash for each request that I copied from the web player requests and it works fine. 


My code just deletes track 1 after I add a track to the bottom so I can keep the playlist length the same.  Here is my code that pulls the playlist data and deletes track 1 (in python):


#get ID of first track in playlist
resp=requests.get("",{"operationName":"fetchPlaylist","variables":"{\"uri\":\"spotify:playlist:"+playlist_id+"\",\"offset\":0,\"limit\":1}","extensions":"{\"persistedQuery\":{\"version\":1,\"sha256Hash\":\"91d4c2bc3e0cd1bc672281c4f1f59f43ff55ba726ca04a45810d99bd091f3f0e\"}}"},headers={"authorization":"Bearer "+access_token,"client-token":clientToken})
#delete the first track"",json={"variables":{"playlistUri":"spotify:playlist:"+playlist_id,"uids":[uid]},"operationName":"removeFromPlaylist","extensions":{"persistedQuery":{"version":1,"sha256Hash":"47c69e71df79e3c80e4af7e7a9a727d82565bb20ae20dc820d6bc6f94def482d"}}},headers={"authorization":"Bearer "+access_token,"client-token":clientToken})

I've been poking around the api-partners endpoint a LOT. The sha256 hash is generated from a GraphQL definition. I was even able to extract pretty much all of the definitions. However, Spotify no longer includes these in their code, and instead just hides the already generated hash somewhere in the code.

This is important because the definition shows how to use the endpoint. Yes, it would be possible to just write a script to look for the hashes instead, but then the problem is that we don't know how the endpoint works when there is a change. So this is not recommended for production at all.

As for the client token, my experience was that I didn't need it. Weirdly enough, the app-platform was also not required, which was the case before. However, the authorization token is still required. Using an application token doesn't work either, not even for a simple search.

I've seen people writing Python scripts that can create accounts and get the auth token. This might be a possible approach.

Suggested posts