Questions regarding quota extension rejection: Commercial SDA

[practical_hen]

My quota extension has been rejected 3 times so far. It seems every time, there is a different reason and this has cost me a lot of time. The first two times, I have had to clarify on things in the next application submission, but then I just receive a different reason the next time. This last one was that my app is considered a commercial SDA, although I don't think it technically fits that definition per the Developer Terms, so I am hoping for some input from the community.

The main function of the app is to suggests a list of songs to create a playlist from, based on the user's mood/request. This portion of the app works completely independent of the Spotify API. The only use of the Spotify API is to show the user's existing playlists, and to take the already suggested list of songs and create a new playlist.

In the future, the part of the app that suggests the songs will be monetized, giving free users the ability to get up to 10 suggestions per week. Although, free users still have full access to all of the Spotify API from within the app. For example, a free user can still see their existing Spotify playlists, and manually search for songs to create a new playlist with.

The only part that will be monetized is the part of the app that suggests songs to create a playlist from, so that the user doesn't have to know which songs they want ahead of time and manually search for each song.

The app does have a Player (for Spotify Premium) users, but I am now considering removing it so that it qualifies as a non-streaming SDA.

My questions are:

1. Does my app still violate the developer terms even though access to the Spotify platform within the app is not limited/monetized?
2. Will it be more likely to be approved for this use case if the app were a non-streaming SDA?

[Ximzend · Accepted solution]

Hi @practical_hen 

Thank you for reaching out to the Community.

The last quota extension got indeed most likely rejected, because you used the Remote Playback SDK in a commercial app.

Therefore I recommend you to request an extension again when that is removed from your app, as you are already suggest.

I hope this answers your question. If you have any further questions, feel free to ask.

Cheers!

[practical_hen]

I see. That is what I thought. Thanks for the reply. I will make the app a non-streaming SDA and try again.

[Adr182]

I'm in a similar situation to you and have not found the answer. If you're removing the player controls, and assuming that defines your application as a non streaming SDA, then there would be no need to apply for a quota increase at all since you're not using an oauth login for the user.

But if you are still needing the user to do an oAuth to user the playlist scope, the question that I can't seem to find an answer to is whether using "any" scope, or just the "playback" scope would define an app as a streaming or non streaming SDA. Would be great to hear yours (or anyone else's) thoughts on this. 

I am hoping to just use the "user-read-playback-state", "user-modify-playback-state", "user-read-currently-playing" scope, and hoping to find out if that is still deemed as a streaming SDA or not.

[practical_hen]

I do still need to do oauth login for the user in order to display and add to/create playlists. I am still waiting for a response on my latest application so I am not yet sure that my approach of removing the player controls will get my application approved.

From what I can tell, using any of the playback scopes will classify an application as a streaming SDA. Perhaps you might get an exception for the "read-playback" and the "read-currently-playing" scopes, but I would assume that the "modify-playback" would definitely count as a streaming SDA. This is just my guess though as the documentation is super vague about what makes a streaming SDA. In my case, I just removed all playback scopes to be safe.

[Adr182]

Thanks for replying. In my most recent submission, i only use "user-read-playback-state", "user-read-currently-playing". Let me know how you go if it gets approved and what exact scopes you had. It would be much appreciated. And if you get yours rejected again, I'll also be sure to share if my request with just those 2 read statuses get approved as a non streaming SDA

[henrynguyen7]

I just came across this app on Reddit where the author states the following:

"Hi, we comply with the Spotify developer policy because we use the Spotify Remote SDK which means our app doesn't directly stream the music but just tells Spotify which track the Spotify app should play. This makes us a Non Streaming SDA :)"

From https://www.reddit.com/r/SideProject/comments/11yvsu1/we_just_launched_an_app_that_allows_you_to.

So Spotify seems to be quite inconsistent regarding what they're determining to be a streaming SDA vs non-streaming SDA. Which is quite unfortunate for anyone wanting to commercialize their app.

[Adr182]

@henrynguyen7 thanks for sharing!

That's insane they got it approved. We used similar scopes for a similar use case and had ours rejected. The thread is 2 years ago though so it could be a chance that the tightening up to their rules only happened recently in the last 12 months.

Fingers crossed my next application goes through and i'll share for anyones benefit since its super hard to find info.

[practical_hen]

Funny enough, this is exactly how my app worked as well. Just told Spotify what to play remotely. Still got rejected as a Streaming SDA.

[practical_hen]

I unfortunately, though not surprisingly, got rejected yet again. This time though, for something else - I need to show my EULA to the user and have them agree on first use. So I guess removing the playback scope did work to get past their Streaming SDA policy.