Possible bugs in the Web API and it's OpenAPI Specifications

[WardDG]

Plan

Free/Premium

Country

Belgium

Device

Laptop

Operating System

Windows 10

My Question or Issue

Hello all, for my master thesis I'm working on a tool that is able to generate test for a REST API based on it's OpenAPI Specifications. To evaluate the tool I ran it on the Spotify Web API and I think I might have encountered some bugs.

First, I encountered 2 possible bugs in the OpenAPI Specifications (I got the OpenAPI Specifications from here: https://developer.spotify.com/reference/web-api/open-api-schema.yaml, so if these are outdated then this might not be valid anymore). First, in the PUT operation of the "/playlists/{playlist_id}/images" endpoint, there is "required: true" placed under the schema in the request body, but I think this might have to be placed directly under the "requestBody:" itself instead of under the schema. Next, the GET operation of the "/playlists/{playlist_id}/tracks" endpoint contains the "playlist-read-private" scope, but the GET operations under the "/playlists/{playlist_id}", "/playlists/{playlist_id}/images" and "/playlists/{playlist_id}/followers/contains" do not contain this scope. This does not seem correct to me, since I feel like these should also be locked behind a scope in case the playlist is private. This also kind of leads into a possible bug with the Web API, since when trying to execute the GET operation on "/playlists/{playlist_id}/tracks" and all these other playlist endpoints without the "playlist-read-private" scope, they were still accessible, so either none of these should contain this scope, only "/playlists/{playlist_id}/tracks" should contain the scope, but there is  something wrong with the authorization or all of them should contain the scopet and there is something wrong with the authorization.

Next, there are 2 other possible bugs I found in the Web API. First, the GET operation on the "/audiobooks/{id}/chapters" always returns an internal server error when executed with a valid access token. This might be due to the fact that, from what I've read, audiobooks on Spotify have been discontinued, but even then, none of the other audiobook endpoints return an internal server error. Second, the GET operation on the "/me/player/queue" endpoint always returns "Forbidden" when executed by a user with the correct scope. This might be due to the fact that the test users used don't have a queue, but even then I'd expect either an empty response or a different error then "Forbidden". It seems especially strange to me since all the other "/me/player/..." endpoints work without any issues.