Missing pagination information in /v2/playlist/{id} and included missing in /playlists/{id}/relationships/items

[semohr]

Hey guys,

Thank you for providing an open API!

I've a playlist with more than 20 tracks in it. I'm doing a request with include=items to /v2/playlists/{id}. I was expecting to be able to iterate the response but there is no next link included for the playlist only for the relationship items.

If I use the relationship links to iterate all items I do not get the included data (track attributes) returned. Am I doing anything wrong or is this a genuine oversight?

---

Examples

For reference, in this example the returned data does not include a root level links.

curl --request GET \
  --url https://openapi.tidal.com/v2/playlists/YJ5Hxu5XwySm8H7kN2AuAuzvbo8kuV01ErqwMNZTBCQCXwxJUaR?include=items \
  --header 'Authorization: Bearer [REDACTED]'

Next up if I use the relationship links there is no included field even though I use include=items.

curl --request GET \
  --url https://openapi.tidal.com/v2/playlists/YJ5Hxu5XwySm8H7kN2AuAuzvbo8kuV01ErqwMNZTBCQCXwxJUaR/relationships/items?include=items \
  --header 'Authorization: Bearer  [REDACTED]'

---

Unsatisfying workaround

It is possible to circumvent this problem by getting the playlist relationships first and than retrieving the track information but this is basically an 2x multiplier to the number of requests and for big playlists this adds alot of wait time since your guys rate limiting is pretty strict imo.

For instance for a playlist with 300 tracks the wait time goes from already 75s to more than 150s because each request has to wait an additional 5s for the rate limit tokens to replenish.

I would highly appreciate some feedback!

Best, Sebastian

[stefanmoro]

Hey @semohr,

Turns out there was a bug in inclusion logic for relationships with meta, should be fixed now. Can you please try again?

[semohr]

Thanks for the quick fix!

The /playlists/{id}/relationships/items endpoint seems to correctly return the included items now.

The /playlists/{id} endpoint still does not include a way to paginate the response, right? This makes the include parameter for this endpoint a bit counter intuitive. You would always want to use the /playlists/{id}/relationships/items endpoint to get the included data and account for pagination with it. Maybe a remark in the documentation would be helpful.

If I had a say in it, I would just remove the include parameter from the /playlists/{id} route entirely as in my opinion the use of it will induce problems in almost all applications down the road.

Feel free to close the issue :)

[stefanmoro]

Glad to hear that it worked, will close the issue.

As the /playlists/{id} endpoint returns a single playlist object, not a collection, there is no pagination on that response.

TIDAL API aims to follow the JSON:API standard, feel free to check that out for more information about the format.

[semohr]

Inclusion of related resources is not a requirement. I think omitting it for this route would reduce some headaches and prevent some issues for api users.

More of an ergonomics problem though, not really a big issue.