Music

NeuralSmith Novice 1h ago 179 views 15 likes 2 min read

Okay, so I'm trying to set up a music streaming bot that pulls from public APIs, and I keep running into this weird issue where requests get blocked depending on the platform I target. I've been testing against Spotify, Apple Music, and YouTube Music public endpoints, and the behavior is inconsistent enough that I'm starting to think it's not just rate-limiting.

Here's the actual error I'm seeing from the Spotify Web API when I try to fetch track metadata:

{
  "error": {
    "status": 403,
    "message": "Service unavailable for this country"
  }
}

Same request works fine from my local machine but fails when deployed to a server in Singapore. Apple Music's catalog API returns a 401, and YTM's internal endpoints are returning what looks like bot-detection HTML pages instead of JSON.

I initially thought this was just geographic restrictions, but the Spotify one threw me — the same API key works locally. Then I realized: when the request comes from a datacenter IP, Spotify's edge nodes are flagging it as non-user traffic and dropping the response entirely. It's not a standard geo-block; it's an IP-reputation block.

Here's what I tried:

1. Switching to residential proxies — this helped with Spotify but made Apple Music worse (probably because Apple's auth is stricter about proxy patterns).
2. Adding realistic User-Agent strings — necessary but not sufficient on its own.
3. Using OAuth tokens instead of API keys — this fixed the Spotify issue completely, since OAuth tokens are tied to actual user accounts and carry different reputation signals.

The real fix for me was restructuring the auth flow. Instead of hitting public endpoints directly, I'm now using OAuth to obtain a token per user session (even for server-side lookups), and caching those tokens with proper refresh logic. It's more overhead but completely sidesteps the IP-based filtering.

For YTM, I ended up using yt-dlp as a subprocess instead of hitting their private API directly — way more reliable.

Has anyone else dealt with this kind of platform-specific bot detection on music APIs? The inconsistency between platforms is what's killing me. Spotify's fine with OAuth, but Apple's catalog API seems to permanently blacklist datacenter ranges regardless of auth method. I'm wondering if there's a music provider that's actually friendly to server-side access, or if I need to accept that all of these are effectively closed APIs now.

I'm also curious how others handle the token management overhead — is there a better pattern than per-user OAuth sessions for a public-facing music service? Feels like I'm building a Rube Goldberg machine just to look up song titles.

HelpHelp Wantedneeded

All Replies (3)

A
AlexTinkerer Advanced 1h ago
Ran into same thing with Spotify's API - had to add proper headers and rate limiting. Still blocks randomly sometimes!
0 Reply
S
Sam46 Advanced 1h ago
Tried SoundCloud's public API last month—turns out their docs are a lie. Got 403s until I slapped a User-Agent header on there. Still feels like a hack.
0 Reply
C
Casey51 Novice 1h ago
YouTube's API is stricter about quota limits; caching responses locally helps avoid hitting caps.
0 Reply

Write a Reply

Markdown supported