Now that users can view their recently played tracks in the apps...

[JoaaoVerona]

Can we list more than 50 of the most recently played tracks of users from our systems, in the API https://developer.spotify.com/documentation/web-api/reference/#endpoint-get-recently-played ?

Currently, it allows us to fetch only the 50 most recent tracks. However, since in the apps, users can now view a much higher number of their tracks played in the past, can't this limitation be relaxed in this API?

Thanks.

[Hubo]

Hey @JoaaoVerona, thanks for your post here!

Hmm, let’s dive into this. Are you able to navigate the list of recently played tracks with the before attribute? That might help get more recently played tracks. Let me know how it goes.

Have a great day,

Hubo

[JoaaoVerona]

Hi Hubo, thank you for your prompt reply!

Unfortunately, no -- that's what I expected too. However, after I send an initial request with limit=50, the API responds with the 50 most recent tracks, along with the cursors "after" and "before" to fetch it again. However, by using the cursor "before" with the timestamp returned by the API, no tracks are returned at all.

To demonstrate it -- I send the initial request, with no after/before cursors and limit=50:

Then, the request responds me successfully with the 50 most recently listened tracks, and with the after/before cursors that I could use in the next requests:

Then, calling the very same API again, but with the cursor before=1617655258250 (that is, to fetch all tracks played before the timestamp of the last returned track in the first API call):

It returns me no tracks at all:

Also, AFAIR, this has been behavior of this API ever since 2018 -- only 50 tracks are returned at all. However, it would be really great if the API team could relax this limitation, now that this information is freely available in the Spotify clients, as this would enrich API clients with many new possibilities and use cases.

Thank you!

[Hubo]

Hey @JoaaoVerona, thanks for your detailed explanation here!

Got it! Thanks for trying this and reporting this back here. The right teams are keeping an eye out on this board and reading the feedback you give to improve the API. Hopefully this limit can be a bit more relaxed.

Could you give me a bit more background around how you'd use this endpoint in your app? That can help the Developer team get a bit more insight into how developers would like to use this.

Thanks again, happy coding,
Hubo

[JoaaoVerona]

Hubo,

Thank you for your time. I'm really hoping that the API team can have the resources and "permissions" necessary to relax this limit, as that would be beneficial to many API consumers.

By increasing the amount of "recently played tracks" we could fetch from users, systems that integrate with the Spotify API could:

• implement a scrobbling-like system with much less overhead, less rate-limited API calls, and also, with less overall impact on Spotify's API;
• create algorithms to analyze the listening habits of users, considering a much bigger dataset -- 50 last tracks are not sufficient to offer information which would require fetching the played tracks of users along some period, like "which time of the day do you most listen to Spotify?", since people like me (and many others) listen to 50 tracks in a period of like 4-6 hours (if we consider tracks of 4 minutes, then we would have a lower bound of 50x4=200 minutes, just 3.5 hours)
• analyze listening habits over time, like "how's your mood varying this week?", which would also need to consider a much bigger span of tracks (along days, weeks, etc).

Theoretically, a system could already spam Spotify's API calling this "recently-played-tracks" endpoint every 3 hours, for example, and constructing a list with the users recently played tracks (just like scrobbling); but, again, that is not viable, particularly when you have 20,000 monthly active users in your application (my case here).

Thank you!

[Johnny_J]

I'm very interested in this as well.

The private API endpoint that Spotify uses in its own apps (https://spclient.wg.spotify.com/listening-history/v2) has no such limitation, so that means the data would obviously be available.

Even increasing the total number of items returned from GET /v1/me/player/recently-played to like 250 would already help a lot.

I really hope there isn't any political motivation behind the reason this endpoint is so restricted.

[javoG]

Having the same problem.

I've been searching for an answer and I've seen that this problem has been for a long time.

Please fix it as soon as possible!

[chorgan182]

+1 for this!

In the meantime, at least update the documentation to be accurate. I'm new to APIs, python, webapps, and Spotify for developers. I assumed Spotify's endpoint documentation was correct, so it took me 3 full days of troubleshooting to find out it was not something I was doing wrong.

Thanks for posting; I'd still be lost if I hadn't found this.

[tabiday]

Hi - I'm new to this API and am currently unable to use the before/after parameters to access a specific part of a user's browsing history. This is pivotal to my app - is this a bug with the API?

[VortexHero]

Having the same issue -- is there going to be a fix to retrieve more than the last 50 recent tracks?

[djosborne10]

Bump! I was working on an app to convert previous song history into a playlist without having to do it by hand only to find that it's impossible 😞

Any plans to extend the history past 50 tracks?

[zdoctor]

+1

It would be incredibly helpful to remove the limit or increase it to minimum 250-300

[ChrisBeDeveloper]

Any updates on this topic? 

[pb-livin]

+1
i dont get how apps like these are able to retrieve them
https://developer.spotify.com/community/showcase/discover-quickly/

[Ximzend]

Hi pb-livin,

What do you mean with "apps like these are able to retrieve them"?

Discover Quickly doesn't have the feature to list Your Recently Played tracks; only Your Top Tracks. And that uses another endpoint called Get User's Top Items.

Cheers,

[recently_played_trac]

It's baffling to me that there exists an internal API that can apparently provide more than 50 tracks and also manages to get podcasts plays (which the public API cannot) and it does not suffer from the issue of not tracking plays that were skipped part of the way through, and yet, we're stuck with this.

[jul77100]

Wow I'm not the one who gets the same issue ! 

[DorianRichard]

+1
At least update the docs

[chriscorallo]

+1

I'm currently having the same issue. 😞

[rokahash]

+1

Yes, I would like to have more than 50 history too.