Why we’re banning music bots that stream from YouTube, SoundCloud, and other third-party platforms and what it means for developers & servers

Short version: Infinity Bot List will no longer accept or verify bots whose primary function is to stream, rebroadcast, or otherwise deliver copyrighted music from third-party platforms (YouTube, SoundCloud, Bandcamp, etc.) into Discord voice channels. This isn’t arbitrary it’s the result of legal, technical, and policy realities that make these bots risky for platform operators, bot developers, and community owners. Below is a comprehensive explanation of why, what changed historically, the real world risks, and practical alternatives and migration steps for bot authors.

---

1) Quick history: what happened with the big music bots

In 2021, major Discord music bots that streamed audio from YouTube were hit with legal pressure and cease and desist letters most notably Groovy and Rythm and the services shut down rather than fight. That event exposed the brittle legal/technical foundation on which many music bots ran.

Those takedowns were a wake up call across the ecosystem: platform owners and rights holders started making clear that large scale, server side rebroadcasting of platform content (especially when done by reverse engineering or scraping) is not something they’ll tolerate. In short: the status quo for “just add a music bot” collapsed almost overnight, and it demonstrated how much liability and operational risk those bots carried.

---

2) The legal & contract picture (TL;DR: complicated and risky)

There are three overlapping legal/contract drivers that make this a problem:

a. Platform terms of service / API policies.
Major platforms (YouTube, SoundCloud, Spotify, etc.) expose official APIs with explicit developer policies that limit how content can be accessed and played back. Violating those terms (for example, by scraping private endpoints or extracting audio from video) is a breach of contract and can lead to revoked API access, DMCA notices, and cease and desist letters.

b. Copyright law & rights holders.
Many tracks are protected by multiple rights (sound recording, composition, performance). Rebroadcasting copyrighted tracks without the right licenses exposes bot operators and hosting providers to takedown notices and legal action. While laws (like the DMCA in the U.S.) provide notice and takedown channels and limited “safe harbor” protections for platforms, those protections don’t make it safe for a third-party bot to rebroadcast copyrighted content at scale without express licensing.

c. Industry enforcement pressure.
Major rights holders and platform owners actively pursue large, high visibility cases to protect revenue streams and licensing deals. The Groovy / Rythm shutdowns were driven by that enforcement posture platforms and labels won’t let unauthorized large scale rebroadcasting stand.

Combine the three and you have a fragile business model: a bot that works today (by scraping a site or using unofficial tricks) may be legally and technically shut down tomorrow.

---

3) Technical & operational problems (why it’s not just “a policy”)

Even ignoring legal exposure, music bots cause practical headaches:

• TOS breaking techniques are fragile. Bots that relied on scraping or on private APIs tend to break when platforms change their endpoints or rate-limit / block them. Those breakages are not only inconvenient they’re how platform owners detect non compliant clients and start enforcement actions.
• Bandwidth and hosting cost. Streaming audio at scale uses real bandwidth and compute. Free or hobby bot projects frequently underprice this cost and then run into abuse or cost issues.
• DMCA takedown surface. Hosting recorded or rebroadcast audio increases the surface area for takedown requests and subpoenas for user data.
• Quality & reliability. User experience is often poor compared with official clients; when a bot fails the server owner bears the support burden.

All of the above make these bots a high friction thing to host, list, or promote as a verified item on a public catalog like Infinity Bot List.

---

4) What platforms allow (and important limitations)

Not all music APIs are the same some things are allowed if you follow the rules and accept the constraints:

• The Spotify Web API and Web Playback SDK are intended for building integrations, but they have restrictions (for example, the Web Playback SDK requires a Spotify Premium account and cannot be used as a server-side streaming engine for general broadcasting). Spotify explicitly limits playback and commercial streaming use and has developer policies that apps must follow.

• SoundCloud's public APIs explicitly prohibit their use for developing Discord bots. Their API Terms of Use state that developing a Discord bot is not a permissible use case. Therefore, using SoundCloud's API for this purpose is not allowed under any circumstances.

• YouTube's API and Terms do not permit circumventing the service (e.g., extracting audio/video or rebroadcasting it outside the authorized clients). Using unofficial or private endpoints to stream audio to Discord violates YouTube's developer policies and was the core reason large bots were targeted.

Bottom line: “Integration” ≠ “free server-side rebroadcast.” If an API or SDK requires a logged-in user or a premium account, you can’t lawfully turn that into a server-side, multi-server streaming service without additional licensing and agreement with the platform.

---

5) What Infinity Bot List is enforcing and why

We’re tightening our verification and listing rules to protect three groups:

1. Bot developers: so you don’t invest time into a bot that will be shut down, get C&D’d, or lose verification.
2. Server owners: so communities aren’t put at legal risk or left with a broken bot that exposes them to takedowns.
3. Infinity Bot List: so we avoid listing or promoting tools that violate platform policies or are likely to be taken down.

Concretely: bots whose primary purpose is the server-side streaming/rebroadcasting of copyrighted music from YouTube, SoundCloud, or similar third party consumer platforms will be denied verification or delisted. We’ll allow bots that use approved APIs properly, offer metadata/links, require user tokens when playback is user-driven, or that use properly licensed/royalty-free audio.

---

6) Practical alternatives how to rebuild a “music” bot that won’t get you in trouble

If you authored or maintain a music bot, you have options that are legal, stable, and user-friendly:

A: Use official SDKs within their limits

• Use Spotify for metadata, playlists, and user-initiated playback via the Web Playback SDK (but remember that Web Playback requires a Premium user and is intended to run in the user’s client). It’s not a server-side broadcast solution.
• For SoundCloud, only play tracks that are explicitly “playable” via the API and follow the API Terms and surface them as links or client side plays when required rather than server-rebroadcast.

B: Use licensed catalogs or streaming services designed for third- party embeds

There are services that offer music licensing for background/communal use (Epidemic Sound, Artlist, etc.) or embeddable players intended for external sharing. These come with real licensing costs but remove most of the legal risk.

C: Use royalty-free / public-domain libraries

If your bot plays royalty-free content, Creative Commons music (with compliant attribution), or public-domain audio, it can remain a voice-channel player without the same infringement risk. Good sources: Free Music Archive, ccMixter, etc. (always check the license).

D: Provide discovery & linking rather than serving audio

Build bots that search playlists, queue links, create synchronized listening sessions by linking to official players, or control user client playback where the user’s client (not your server) streams the music. This “link & control” model is much safer.

---

7) A developer compliance checklist (practical items)

If you’re working on a bot that touches music, check these boxes:

• Do not scrape or use unofficial/private APIs to extract audio/video.
• Use only documented platform APIs and obey developer policies. (Read them regularly.)
• If you use Spotify playback features, ensure you understand Premium and Web Playback SDK limitations.
• Maintain a public privacy policy and terms that disclose how you use third-party services and user tokens.
• Implement a DMCA takedown handling workflow and keep logs for troubleshooting.
• Prefer licensed/royalty-free content or user-initiated playback for streaming.
• Avoid offering “broadcast” style playback (one server-side stream piped to many users) unless you have explicit licensing.

---

8) Migration guide steps to move away from banned behavior

1. Identify the code paths that fetch/stream audio (where you pull raw audio or bypass official SDKs).
2. Replace server-side audio streaming with one of:
   • Client-side controlled playback via a sanctioned SDK (user must be logged in where required).
   • Playing licensed/royalty-free files from your own CDN that you have rights to distribute.
   • Providing metadata + deep links so users open the track on the official platform.
3. Update your docs and privacy policy to state which APIs you use and how user data is handled.
4. Notify your users in your bot’s server and release notes about the change and why (legal & reliability reasons).
5. Request re-verification once the bot is compliant with the rules we publish.

---

9) FAQs

Q: Can I still make a “music bot” at all?

A: Yes but it needs to avoid server-side, unauthorized rebroadcasting of copyrighted platform content. Build around legal APIs, licensed catalogs, or royalty-free audio.

Q: What about SoundCloud is it allowed for Discord bots?

A: No. SoundCloud’s public APIs explicitly prohibit their use for developing Discord bots. Any attempt to use SoundCloud for server-side playback or rebroadcasting in Discord would violate their API Terms of Use and is not permitted under any circumstances.

Q: Can I use Spotify?

A: Spotify is useful for metadata, playlists, and user-driven playback, but the Web Playback SDK requires Premium and is designed to play in a user client rather than act as a server-side broadcaster. Read Spotify’s developer policies before implementing.

Q: Is Infinity Bot List being draconian?

A: We’re trying to be realistic: we want to avoid promoting or validating bots that will almost certainly be shut down, place communities at legal risk, or violate platform terms. This policy protects developers, server owners, and the long-term health of the ecosystem.

Q: What About SoundCloud’s Official Discord Bot?

A: Some developers may notice that SoundCloud now has its own official Discord bot: discord.soundcloud.com. This bot is fully authorized by SoundCloud and developed in collaboration with trusted partners.

---

10) Closing & legal note

We know music is core to many communities and that “music bots” were a beloved part of Discord life which makes these changes painful. Our policy aims to balance community features with legal reality and long-term stability. If you’re a developer and want help migrating your bot or crafting a compliant plan, we can review migrations, suggest API-first designs, and help you draft user-facing announcements.

Not legal advice. This post summarizes public policies, history, and best practices if you need legal certainty (for example, to negotiate licensing or respond to a takedown), consult an attorney experienced in copyright and tech contracts.