Help Wizard

Step 1


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


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:



Now it instead returns a base64-encoded string:



Which when decoded becomes:


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.


Accepted Solutions
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?

View solution in original post

41 Replies

Today, May 3rd, the string returned now correctly looks like a snapshot ID. However, the endpoint itself has stopped working and it simply returns the same snapshot ID as the input, so no changes to the actual playlist. Seems like this endpoint is under active development.

Same here !

Since yesterday, I can't reorder my playlists using this endpoint.

Same here. Replace tracks doesn't work, but adding tracks does. Looks like they made changes to the endpoint overnight on a production server, without any advance warning or they're having some kind of bug.

In any case, sending a PUT request to{playlist_id}/tracks results in a 405 error at the moment, whereas this has always worked and should still work according to documentation.

Same problem here, returns the same snapshot ID with no changes to the actual playlist.

Yeah, same here. It will change when you add to the playlist (POST), but not when you re-order / change the playlist (PUT). Looks like someone disabled the PUT request for this endpoint even though this is still the official way according to the documentation so it looks to be a bug. It also wouldn't make any sense as only having the option to add tracks to a playlist would greatly reduce the functionality of the API.

Thanks for reporting this. We recently did do an update on this endpoint, we will look into this and get back as soon as we have more information.

It looks all related to the above posts, but when I try to move a track to the end of a playlist, e.g. there are 4 tracks in the playlist, and I'm using {"range_start": 1, "insert_before": 4}, I get a "Given positions are out of bounds" error message.

My code has been working flawlessly for many months until yesterday.


If I try {"range_start": 1, "insert_before": 3} it appears to work but the playlist is not modified.

#0 is the first track, so you need to write {"range_start": 0, "insert_before": 3} to move the first track to the 4th position.


When you tried  {"range_start": 1, "insert_before": 3}, the track #2 is supposed to be moved to the 4th position. But for all of us since yesterday, we get a snapshot_id but the playlist is not modified.

Thanks. The documentation says "To reorder the first item to the last position in a playlist with 10 items, set range_start to 0, and insert_before to 10". Maybe that has changed recently? I'm pretty sure that's how it used to work at least. It would make sense to me, because in my mind if you insert before the last track, the existing last track would still be last track. What makes sense and what actually happens may be two different things of course.

Sorry, I was probably wrong with the "insert_before". I'm confused now. You seems more used than me with this endpoint 😉

Seems like the issue is still ongoing. Multiple days so far. Would've expected the live API to have some method of reverting changes that actively break things rather quickly. Any update on this?

Can't believe it's May 6th and this issue is still not resolved in Production,

We found a bug in the new code. Instead of using the insert_before parameter, we were re-using the range_start parameter. That would explain why attempts to re-order would not actually move anything, since it was being moved to the same position it was already in. Is it now working as expected for you?

Hi Lambert,

Thanks for the reply and for looking into this. We're currently still getting a 405 error unfortunately when trying to replace the tracks in the playlist. This is with PUT and a bunch of URIs. Everything worked perfect until 3-4 days ago.

We use PUT on the /playlists/[id]/tracks endpoint to first replace the songs in our playlists with up to 100 new ones. And then we use the POST request if we need to add more songs beyond the first 100. The POST request still works fine, but the PUT throws a 405 error that wasn't there before a couple days ago. Hope that helps. 🙂

Thanks Lambert. It still does not seem possible to move a track to the end of a playlist. Testing with a playlist with 9 tracks, I can move a track to the last-but-one position (insert_before: 8), but when I try to move it to the end (insert_before: 9) I still get the 'out of bounds' error.

I still can't reorder my playlists using this endpoint. A snapshot_id is given back but the playlist order is the same.

It works now 👍

Interesting. Still a 405 error over here with the PUT request unfortunately.

@LambertSpot, first of all, thank you for handling/communicating these issues.


Even though playlist updating is kinda working right now, there are still some issues:


  1. The returned snapshot_id is exactly the same as the one specified on the request body; this data is particularly important for API consumers that must call this API many times in sequence, since we need the last valid snapshot ID to be specified on the request body of the next API calls. This same issue also happens on other playlist-related APIs (like the DELETE variation of this one, for removing playlist items).
  2. Moving a track to the end of a playlist, as @shuffles mentioned, is indeed not working (for me, the API is returning 502 Bad Gateway with an empty message).

Suggested posts