Is My Playlist App Considered a Streaming App?

[Mignot12]

Hi everyone,

My main question is: Can I provide playable playlists without my app being considered a “streaming app,” so that I can make commercial use of it?

I've read the Spotify API Terms of Use and many forum topics, but I still feel unclear about how my project fits—specifically whether a playlist-based app like mine would be considered a streaming app.

I'm developing a web app that helps users explore and organize their Spotify library and playlists in a new way—mainly focused on genre discovery and curation (I'd rather not share too many details yet to protect the idea).

Here are a few specific questions:

Playback: Can I provide a full-featured media player to play the user's tracks entirely through the app?

App Views: My app will have two main sections—one with my custom playlist system, and one as a simple filtered list of the user's saved music. Is the second one allowed without being considered a streaming app?

Discovery Features: For each playlist, can I provide a discovery component that recommends tracks?

Non-Library Playlists: Is it allowed to show curated or generated playlists made up of tracks not already in the user's library?

User Files: Can I allow users to upload their own music files to the app (only available for personal use)?

Other Platforms: I assume I cannot stream music from other platforms—does this restriction also apply to previews, or is metadata and playlist info acceptable?

Thanks in advance for any help or clarification you can provide!

Andreas

[Ximzend]

Hi @Mignot12! Thanks for reaching out on the Community and sharing details about your app idea.

It sounds like a really interesting project focused on genre discovery and curation

You're asking a great question that many developers grapple with when building on the Spotify platform: how to provide useful features without being classified as a "streaming app" and thus limiting commercial options. Let's break it down based on the sources and our previous chat.

The key distinction is between a Streaming SDA and a Non-Streaming SDA.

• A Streaming SDA is one that lets users play music sound recordings directly within your app using Spotify's tools like the Web Playback SDK or playback control endpoints.
• A Non-Streaming SDA is one that doesn't do this.

Why does this matter? Commercial use is generally restricted for Streaming SDAs (you can't charge users, run ads directly on the streaming part, etc.). However, limited commercial use is permitted for Non-Streaming SDAs, like selling advertising or access. A playlist manager app is even given as an example of a Non-Streaming app where charging a monthly fee is allowed.

So, to make commercial use possible, your goal is for your app to be a Non-Streaming SDA. This means avoiding embedding a full media player that streams Spotify music sound recordings directly within your web app.

Let's go through your specific questions:

• Playback: Providing a full-featured media player within your app to play Spotify tracks would likely classify it as a Streaming SDA, which restricts commercialization. Spotify generally recommends that you always link out to the official Spotify app for playback when the client is available on the user's device. Using Spotify metadata and cover art requires you to link back to the content on the Spotify Service anyway.
• App Views: Having sections that manage and display a user's library or curated playlists, like your filtered list or custom playlist system, is absolutely fine and aligns well with being a Non-Streaming SDA, provided these sections don't offer embedded playback using the Spotify Platform. When displaying Spotify Content (metadata, artwork), remember to clearly attribute it with Spotify Marks and link back to the content on Spotify. Also, be careful not to seat Spotify content next to content from similar services.
• Discovery Features: You can retrieve and display information about content from the Spotify catalog. However, please be aware that for new applications, access to certain Web API endpoints related to discovery, such as 'Recommendations' and 'Related Artists', is being restricted starting November 27, 2024. You also cannot use Spotify Content to train machine learning or AI models or for building user profiles to target advertising.
• Non-Library Playlists: Yes, you can show curated or generated playlists featuring tracks from the Spotify catalog, even if the user doesn't have them saved. As long as you attribute the Spotify Content and link back to the Service, this is permissible and doesn't make your app a Streaming SDA on its own.
• User Files: The developer documentation focuses on integrating with the Spotify Platform and Spotify Content. There's no indication in the sources that handling users' local music files is a supported or permitted use case for apps built with these tools.
• Other Platforms: You are prohibited from integrating the Spotify Platform, Service, or Content with streams or content from another service. This restriction likely extends to previews. While displaying metadata from other services isn't explicitly forbidden in the sources, the rule about not seating Spotify content next to content from similar services makes combining metadata from different sources in a single view tricky to do compliantly.

To summarize: to make your app commercially viable, focus on building it as a Non-Streaming SDA. This means your core functionality should be around exploring, organizing, and curating Spotify data, and you should direct users to the official Spotify app for actual playback. Make sure you're complying with the Design Guidelines when displaying content and the data handling requirements in the Developer Policy and Terms.

I hope this helps clarify things! Let me know if you have any other questions.

[Mignot12]

Hello Ximzend,

Thanks again for your detailed answer — it really helped clarify how to structure the app within the boundaries of Spotify's platform policy, especially around the distinction between Streaming and Non-Streaming SDAs.

I have a follow-up question regarding content that isn’t sourced from Spotify, and I’d love your guidance to ensure full compliance.

In my app, I’m building a genre discovery feature with multiple layers:

• First, for each genre, I show a short description along with 1 or 2 embedded YouTube music videos for iconic tracks (as context, not for full music streaming).

• Then, I present Spotify-based previews for the user's own saved tracks that are related to that genre, with some basic stats like count and total play count.

• Finally, in a separate section, users can upload their own local audio files (MP3s, WAV, etc.) and manually link them to genres. This would allow users to build personal genre-based playlists with their own files only — no Spotify playback or preview happens in this area.

In this structure, Spotify content is never mixed in playback or playlists with YouTube or user-uploaded content, and each section is visually and functionally distinct.

Would this be considered compliant with Spotify's Developer Policy?

One more quick question:
Would it be allowed to let users rate Spotify tracks (e.g., 1–5 stars) within the app, where these ratings are stored internally in my own database and used only for the user’s own experience (e.g., filtering and building custom playlists based on personal preferences)?

Thanks again for your help and for the thoughtful support on this — I really appreciate the time and insights!

Mignot12

[Ximzend]

Hello Mignot12,

Thank you for your follow-up questions! I'm glad the previous response was helpful, and I appreciate you seeking further clarification to ensure compliance. Let's look at your genre discovery feature and the track rating idea based on the Spotify Developer Policy and Terms you've.

Regarding your multi-layered genre discovery feature:

1. Genre description and embedded YouTube music videos:

   • Your plan includes showing genre descriptions and embedding YouTube music videos as context. While genre descriptions themselves are likely fine, integrating embedded videos from another service like YouTube within an application that uses the Spotify Platform appears to present a compliance issue according to the Spotify Developer Policy and Terms.
   • Specifically, the Spotify Developer Policy states, "Do not create any product or service by integrating the Spotify Platform, Spotify Service or Spotify Content with... streams from another service". Similarly, the Widget Terms of Use (which apply if you use Spotify Widgets, but also reflect general principles) prohibit creating a product or service by integrating the Spotify Platform, Spotify Service, or Spotify Content with "streams from another service".
   • Even though you intend these videos for context and not for full streaming of Spotify Content within your app, the act of embedding content (which includes streams) from YouTube is a form of integration with content from another service. This falls under the broad prohibition outlined in the Spotify Developer Policy and Widget Terms of Use.

2. Spotify-based previews of user's saved tracks + stats:

   • Using "Spotify-based previews" (presumably Audio Preview Clips) for user's saved tracks to provide context for the genre seems like a permissible use case for promoting or contextualizing content.
   • The Spotify Developer Policy requires that Audio Preview Clips must be accompanied by a link back to the applicable content on the Spotify Service. They also cannot be offered as a standalone service or product. Using them to preview saved tracks associated with a genre appears consistent with promoting/contextualizing that content, provided you include the required links and attribution using the Spotify Marks.
   • Regarding the display of basic stats like count and total play count for the user's own saved tracks related to that genre, this involves using data obtained from the Spotify Platform. The Spotify Developer Terms state that for Spotify Personal Data obtained through the platform, you must obtain explicit consent before using it for any purpose other than displaying it back to the user on your SDA. Displaying a user's own saved track count or play count related to a genre for their personal view within your app appears to fall under displaying the data back to the user, which is permissible with consent and adherence to data handling requirements.
   • Note: The announcement regarding "Updating the Criteria for Web API Extended Access" indicates changes effective May 15, 2025, where extended Web API access is reserved for established, scalable, and impactful use cases. While this doesn't explicitly state that preview URLs are unavailable for new use cases, it suggests that access to certain API functionalities might be limited based on these new criteria, which could potentially impact the availability of preview URLs for your app depending on its nature and scale. However, the rules in the Spotify Developer Policy regarding how to use previews still apply if you have access to them.

3. Section for user-uploaded local audio files + genre linking/playlists:

   • Providing functionality for users to upload and manage their own local audio files (MP3s, WAV, etc.) within your application, even in a separate section with no Spotify playback, also appears to violate the restriction against integrating with streams or content from another service.
   • Both the Spotify Developer Policy and Widget Terms of Use contain this explicit prohibition. While you are keeping the sections visually and functionally distinct, the core issue is the presence and management of non-Spotify audio content within the same application that uses the Spotify Platform.
   • Furthermore, allowing users to build personal genre-based playlists with their own files could potentially be seen as mimicking or replicating a core user experience of Spotify (playlist creation and management), potentially competing with the Spotify Service.

Based on the Spotify Developer Policy and Terms, incorporating embedded YouTube videos and a separate section for user-uploaded local audio files within your SDA seems problematic primarily due to the prohibition against integrating with content or streams from other services.

Now, regarding your quick question about allowing users to rate Spotify tracks:

• You propose letting users rate Spotify tracks (1-5 stars), storing these ratings internally in your own database, and using them only for the user’s own experience (filtering, custom playlists).
• According to the Spotify Developer Terms, you are generally restricted from storing Spotify Content indefinitely. However, you may store Spotify Personal Data (such as user ratings associated with track IDs) as strictly necessary to operate your SDA and for as long as is necessary to provide your SDA to the applicable user. Storing a user's personal rating linked to a track ID for features like filtering and playlist building appears to be strictly necessary for the functionality you describe for that specific user.
• You must handle this data securely, provide clear privacy disclosures, and, critically, when a user disconnects their Spotify account from your SDA, you must delete and no longer request or process any of that user’s Spotify Personal Data.
• The Spotify Developer Terms and Data Protection Appendix prohibit selling Spotify Content or other data obtained from Spotify and restrict processing Personal Data for purposes other than performing your obligations under the Developer Agreement or outside the direct business relationship with Spotify. Storing and using ratings for a user's internal filtering and playlist building seems consistent with performing your obligations to provide the SDA's functionality to that specific user and is not a prohibited use like selling the data.

Based on the Spotify Developer Policy and Terms, allowing users to rate tracks and storing these ratings internally for their personal use (filtering, custom playlists based on their own ratings) within your app seems to be compliant, provided you adhere to the strict requirements for handling user data, including security, transparency, and deletion upon account disconnection.

In summary:

• The integration of embedded YouTube videos and a section for user-uploaded local audio files appears to violate the prohibition on integrating with content/streams from other services.
• Using Spotify-based previews (if API access is available) and displaying stats for saved tracks seems permissible with proper attribution and data handling.
• The track rating feature for personal use seems permissible under the rules for handling user data.

I hope this clarifies the points based on the Spotify Developer Policy and Terms!

[Mignot12]

Hello Ximzend,

Thank you again for your thorough and thoughtful guidance — I really appreciate
the time you’ve taken to help clarify these points (and so quickly!).

To confirm my understanding:
*Permissible Features (with conditions):*

-

*Spotify-based audio previews + track stats:*

These are allowed *if*:
-

I include links back to the applicable Spotify content.
-

Data is only used to display back to the user (e.g., showing saved track
counts by genre).
-

I have the user's explicit consent and fully comply with Spotify’s data
handling requirements.
-

*User track ratings (1–5 stars):*

These are permitted *if*:
-

Ratings are stored securely and used solely within the app for features
like filtering or building personal playlists.
-

All user data is deleted immediately upon disconnection from Spotify.
-

The ratings are not used outside the app or sold in any form.

*Prohibited Features:*

-

*Embedding YouTube videos* within an app using the Spotify Platform:

This violates the Spotify Developer Policy by integrating with
streams/content
from another service.
-

*User-uploaded local audio files (e.g., MP3s, WAV):*

Even when placed in a separate, visually distinct section, this
still constitutes
integration with non-Spotify content, which is explicitly prohibited.

*Note on Web API Access Changes (Effective May 15, 2025):*

-

Extended Web API access will be more limited, and Spotify may
restrict access
to features like audio preview clips for new apps unless they qualify as
“established, scalable, and impactful.”

------------------------------

- One point I’d like to better understand:

I’ve noticed that certain applications — like *Lexicon DJ* — offer
Spotify integrations
for playlist management, even though they also support managing and organizing
local music files. For example, their documentation mentions Spotify playlist
creation (Lexicon DJ Manual <>).

Given the clear prohibition in the Developer Policy against integrating Spotify
with streams or content from other services, what enables apps like Lexicon DJ
to legally offer both Spotify playlist creation and local file
management within
the same application?

- And one last point:

If my app is managed by an association that sells access to some of its
data (about the music genres only, nothing to do with users or Spotify
Data), would the app be considered commercial and thus be applied the
related constraints?


Thanks again for your insights — I look forward to your response!

Best regards,

Mignot12

[Ximzend]

Hi @Mignot12 

By looking again at the developer policy, local files might not fall under streaming content from different sources.

But still, you cannot monetize any part of your app if your app plays music through Spotify.