Undocumented API behaviour when fetching tracks

[mgoodfellow]

Undocumented API behaviour when fetching tracks

Issue found of: Circa 2016

Endpoint(s):

• GET /users/{id}/tracks
• GET /tracks/{id}

Scope(s):

• None (application is not using authentication i.e., implicit flow)

Expected behaviour:

A list of tracks as described at https://developers.soundcloud.com/docs/api/reference#users.

Undocumented API behaviour when fetching tracks

Collections

Sending a Postman query using the API URL and the SoundCloud Client ID:

https://api.soundcloud.com/users/40974574/tracks?representation=&client_id=SC_CLIENT_ID&limit=200&offset=0&linked_partitioning=1&app_version=1602577585&app_locale=en

(NOTE: The v2 of the endpoint is required in this case, or a 403 will be returned)

This returns many tracks in the collection.

Using our own Client ID:

https://api.soundcloud.com/users/40974574/tracks?representation=&client_id=XXXX&limit=200&offset=0&linked_partitioning=1

This returns significantly less tracks in the collection.

Individual Track

If we take the example of a specific track which is returned in the first collection, and not the second:

https://api.soundcloud.com/tracks/908781892?representation=&client_id=XXXX

We receive a 404 response, with the following JSON body

{
    "errors": [
        {
            "error_message": "404 - Not Found"
        }
    ]
}

A best guess would imply there is some sort of API block on this user or a subset of their tracks. However, a reason for this is never reflected to the consumers of the API. This is rumoured in StackOverflow threads such as these: https://stackoverflow.com/questions/36360202/soundcloud-api-urls-timing-out-and-then-returning-error-403-on-about-50-of-trac#

It would be great to understand exactly what can lead to this behaviour - whether due to settings known/controllable by the user, or settings that are applied but hidden from the user and they are not aware of e.g. imposed due to licensing restrictions (our best guess) or otherwise

Thanks!

[rahul-sc]

Hi. This behaviour is controlled by the rightsholders i.e., to allow off-platform access of their content via the API or not.

Although, I'm interested in finding out if your use case is to access just metadata or playback?

[mgoodfellow]

Hi @rahul-sc - thanks for the response!

In our particular case, the metadata would be fine. Additional metadata to also confirm there is a restriction on that track due to rightsholders would be ideal.

Our experience is that users are normally surprised they cannot see all of the tracks on our site, and often are not aware of any blocks from their end, or why there would be blocks at all. As we do not have the metadata to hand to specifically confirm that this is the case, it becomes guess work when trying to relay this information back to end users.

If app playback was not supported, but widget playback was supported, we would like to know this information as we could still make widget supported tracks available on our site, but restrict them from showing in the mobile app.

I can understand playback restrictions, but surely the metadata should always be available, even if the metadata is to confirm the existence of the track, and to confirm it cannot be played off-site.

[rahul-sc]

Our experience is that users are normally surprised they cannot see all of the tracks on our site, and often are not aware of any blocks from their end, or why there would be blocks at all. As we do not have the metadata to hand to specifically confirm that this is the case, it becomes guess work when trying to relay this information back to end users.

Perfectly valid reason. Thanks for the feedback. Adding this for internal review as feature request.

[sneljo1]

Hi @rahul-sc - thanks for the response!

In our particular case, the metadata would be fine. Additional metadata to also confirm there is a restriction on that track due to rightsholders would be ideal.

Our experience is that users are normally surprised they cannot see all of the tracks on our site, and often are not aware of any blocks from their end, or why there would be blocks at all. As we do not have the metadata to hand to specifically confirm that this is the case, it becomes guess work when trying to relay this information back to end users.

If app playback was not supported, but widget playback was supported, we would like to know this information as we could still make widget supported tracks available on our site, but restrict them from showing in the mobile app.

I can understand playback restrictions, but surely the metadata should always be available, even if the metadata is to confirm the existence of the track, and to confirm it cannot be played off-site.

Yes, same use-case for me 🙂

[blackarcanis]

I can understand playback restrictions, but surely the metadata should always be available, even if the metadata is to confirm the existence of the track, and to confirm it cannot be played off-site.

Exactly, it's normal that some tracks got the playback restriction. But having access to the metadata should be possible for at least retrieving all tracks and not missing some.

[obrhoff]

This is as well very problematic with paged querys. For example requesting a search with a limit of 10 might result in less than 10 result items (0 results are also possible!). Without a next query url it's not possible to know if there are additional pages to query.

[anikarni]

Hey all. This should now be possible with the newly added access param. Check out yesterday's blog post for how to use it. I'm closing this for now, but feel free to submit another ticket if you find that this solution is lacking ;)