Announcements

Help Wizard

Step 1

NEXT STEP

FAQs

Please see below the most popular frequently asked questions.

Loading article...

Loading faqs...

VIEW ALL

Ongoing Issues

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

Loading issue...

Loading ongoing issues...

VIEW ALL

Update Playlist Items endpoint returning wrong string value or documentation is wrong

Solved!

Update Playlist Items endpoint returning wrong string value or documentation is wrong

The Update Playlist Items endpoint all of a sudden started returning the wrong values when reordering items. As per the documentation it is supposed to return the checkpoint ID as a string:

AAACi5JU+kMmH1WlpKKp8PeBdfLNw0BJ

 

Now it instead returns a base64-encoded string:

MTAyNDIzLDdiZWI1Yzg0YmQ2ZGI1ZWE5YWE4ZmEwOTg4ODYwY2VmZmI2ZTAxOTM=

 

Which when decoded becomes:

102423,7beb5c84bd6db5ea9aa8fa0988860ceffb6e0193

I.e an integer separated with what looks like a GUID.

 

How do I derive the checkpoint ID from this now? It used to simply return the checkpoint ID as a string. If I pass the returned value directly as the input parameter snapshot_id=MTAyNDIzLDdiZWI1Yzg0YmQ2ZGI1ZWE5YWE4ZmEwOTg4ODYwY2VmZmI2ZTAxOTM= I get a 400: Missing or bad version tag error.

Reply
41 Replies

Incrementing my comment above:

 

The first issue ("snapshot_id returned is unchanged") also happens on POST /playlists/{playlist_id}/tracks. Therefore, all playlist manipulation-related APIs (add items, remove items, update items) suffer from that issue.

 

Immediately calling the "get playlist" API right after any of these manipulation-related APIs do return a changed snapshot ID, though. But being required to call it right after any of the other APIs is called just to get the latest snapshot ID would be awful, so I'm hoping this is something that can be fixed on Spotify's side (as in: restore the old, correct behavior).

Thank you for looking into it.

 

It is currently still returning the same checkpoint ID as sent to the endpoint, and changes take effect after some time.

 

On a playlist with 71 songs I am using the parameters (move track at position 10 to position 5):

{'range_start': 9, 'insert_before': 5, 'range_length': 1, 'snapshot_id': 'AAADJkLek3IZvhGgTh2Ek6BJcoc4yycI'}

And it is returning the same snapshot_id: 'AAADJkLek3IZvhGgTh2Ek6BJcoc4yycI'.

Okay, I did some more testing. It seems to actually be reordering the playlist with each call now, but the changes take some time to take effect, and the snapshot ID returned is still the same. Then after some (seemingly random) time the snapshot ID of the playlist also does indeed change, as returned by GET /playlists/{playlist_id}. However, since the time for it to take effect is irregular, it is hard to properly chain reordering as we used to where we input the returned snapshot ID to the subsequent requests. Although, it does seem that repeating reordering requests on the same snapshot ID does work and takes effect after some time, the immediately returned snapshot ID is just not useful then.

 

If it is on purpose that the returned snapshot ID is incorrect, then I will mark this as solved. For my application it is important that the snapshot ID changes because I use the snapshot ID to keep track of the version of the playlist to minimize the number of API requests, and it is hard to know if the request caused the snapshot change or if it was externally changed (e.g. by the user).

Are you sure the reordering works? I have a script running to shuffle the played tracks and it keeps on reordering the same tracks over and over again. 

Thanks everyone for checking, and thanks @JoaaoVerona for the clear summary of the issues. We will continue looking at this, I will write again when we have an update to share.

Great, my shuffle script is working again. 
I only notice that hte snapshot_id stays the same for about a minute before getting updated. For my script not a problem but might for others.

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 like:102423,7beb5c84bd6db5ea9aa8fa0988860ceffb6e0193

I.e an integer (a date) separated with what looks like a GUID. Now it is unclear.

Does anyone know the logic for the new snapshot_id?

I would appreciate a definition or logic.

Thanks Lambert! I'll share the Spotify API server endpoint response below. It looks like the API server is currently just not accepting a PUT request for the /playlists/{playlist_id}/tracks endpoint, where it should (and also did until a couple days ago), which makes it impossible to replace the tracks and update the playlist. Like I said above, adding tracks (POST) works fine, it's just the replacing (PUT) that's not working in our scenario.

Screenshot 2024-05-07 at 16.38.21.png

@ATLAST, the PUT endpoint is working normally for me. Share your request data so maybe I can help you with it.

Ordering tracks works now but the snapshot_id has almost always the same value (a new value each minute)

Hi Joaao, thanks for offering to help.

I'm using the https://api.spotify.com/v1/users/USER_ID/playlists/PLAYLIST_ID/tracks endpoint with a PUT request. Within that request I send the standard authorization token in the headers + uris parameter which is an array of a bunch of uris that should go into the playlist. The expected behaviour with this (and what happened until 5 days ago) is that Spotify removes all tracks from the specified playlist and replaces them with up to 100 new songs as defined in the uris parameter. (We then later use the POST request to add more tracks in case the playlist should have more tracks in total)
This has worked for many years until it suddenly broke 5 days ago.

@ATLAST, if I recall correctly, the endpoints that share the path /users/{user_id}/playlists/{playlist_id} (with the user ID) are no longer supported, since all playlist IDs are now globally unique. They've removed these variations from the documentation for quite some time now, but maybe they still kept the endpoints alive for API consumers that didn't migrate yet, so maybe they now fully discontinued them.

 

Therefore, try changing the URL from https://api.spotify.com/v1/users/USER_ID/playlists/PLAYLIST_ID/tracks to https://api.spotify.com/v1/playlists/PLAYLIST_ID/tracks.

Hey, that's it! Appreciate the help. šŸ™‚

Strange how this is still working with all of the other playlist endpoints then. They're probably phasing it out whenever they update an endpoint and this was the first one to get it I suppose. Thanks again.

My issues (reordering playlists, including moving tracks to end of lists) seem to be fixed now. Thanks šŸ™‚

Has something been "repaired"? How do we get to know?

Would still need a definition of snapshot_id and how it is encoded.

 

Thanks!

Marked as solution

Hi again,

 

  • Ordering should be working properly again. 
  • If you are getting 405, then please check the URL and method combination you are using, you should not be getting it for this endpoint.
  • As for snapshot_id, we have been able to reproduce this issue of it not updating till after some time. We are continuing the investigation on that.
    • As for the logic of the snapshot_id, why do you need to understand that? Does it not work if you use the ID you got?

The comma separated format (BASE64) of the snapshot_id, with a timestamp and a GUID (?) as content, provided extra information for sorting. In my application the timestamp could help me reduce the number of API calls. 

We believe we found the issue with snapshot_id not updating properly (or being delayed). After the fix we have been able to verify that it is returning a new ID after each modification as it should. Is anyone still having any issues with this?

Great!

Will you restore the snapshot_id content/formula as well?

Everything is working for me ! Thanks 

Suggested posts

Staff
Let's introduce ourselves!

Hey there you,   Yeah, you! šŸ˜   Welcome - we're glad you joined the Spotify Community!   While you here, let's have a fun game and get…

Staff
ModeratorStaff / Moderator/ 3 years ago  in Social & Random

Type a product name