Policy clarification for a noncommercial Android playback-queue companion

bewye — Sun, 16 Aug 2026 15:18:49 GMT

Hello Spotify for Developers team,

I am developing Attacca, a small, noncommercial Android companion for Spotify.

Attacca does not play, download, modify, or redistribute audio. While the user is listening in the official Spotify app with shuffle enabled, Attacca monitors the user-authorized current playback. If a track selected by the user begins playing, Attacca uses the Spotify Web API to add one user-selected follow-up track to that user’s playback queue.

Technical details:

- Android application
- Authorization Code flow with PKCE
- No client secret
- No Attacca server
- No advertising, analytics, tracking, or monetization
- Spotify tokens encrypted locally with Android Keystore
- User-created track-pair rules stored only on the phone
- Monitoring is explicitly started by the user and shown with an ongoing Android notification
- Intended only for personal Spotify Premium accounts
- Requested scopes:
- user-read-currently-playing
- user-read-playback-state
- user-modify-playback-state
- user-read-private

I would like to comply with the Spotify Developer Terms and Developer Policy before distributing Attacca beyond my own phone.

The Developer Policy says that an SDA must use one Security Code and may not use more than one Security Code per SDA. I found Spotify’s February 2026 forum response acknowledging an existing application in which users bring credentials from their own Development Mode apps, but that response addressed endpoint changes rather than whether this access model complies with the Security Code policy or permits public distribution. I would appreciate clarification on the following:

1. May each Attacca user register their own personal Development Mode app in the Spotify Developer Dashboard and enter that app’s client ID into their local Attacca installation?

2. Would doing that be considered using multiple Security Codes for the same SDA, even though each client ID belongs to a different user’s personal developer account and installation?

3. If that model is not permitted, is the compliant Development Mode model one Attacca client ID with no more than five allowlisted users?

4. May the Attacca APK and source code be publicly available through GitHub or an open-source Android repository if the working application remains limited to the users permitted by Development Mode?

5. Alternatively, may another developer fork the open-source project, register it as their own separately named SDA, and use their own client ID for personal, noncommercial use?

6. Because Attacca sends a request to add an item to the user’s Spotify playback queue, should Attacca be treated as a Streaming SDA under the Developer Terms, even though all playback occurs in the official Spotify application?

I am not requesting Extended Quota Mode at this time. I am trying to determine whether there is a policy-compliant path for personal use, a small closed beta, and potentially a publicly available but noncommercial open-source application.

Please identify whether the answer represents Spotify’s official policy interpretation, since I need to rely on it when deciding whether Attacca can be distributed.

Thank you.

topic Policy clarification for a noncommercial Android playback-queue companion in Spotify for Developers

Policy clarification for a noncommercial Android playback-queue companion