Fixing 403 Country Errors in Spotify and Apple Music APIs

Looking to build a music streaming bot that pulls from public APIs? You're not alone in hitting the dreaded "Service unavailable for this country" error (403). I recently ran into this while testing Spotify, Apple Music, and YouTube Music endpoints from a Singapore-based server. Turns out, it's not just a geo-block — it's an IP-reputation block. Here's what happened and how I fixed it:

The Problem: IP-Based Bot Detection

I was expecting standard rate-limiting or region restrictions, but the behavior was more insidious. From my local laptop, the Spotify Web API worked fine:

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

But deploy that same code to a cloud server in Singapore, and suddenly the API refuses to play ball. Apple Music's catalog API started returning 401s, and YouTube Music's internal endpoints spit out HTML pages instead of JSON — clearly flagging me as a bot.

The root cause? The streaming services are using sophisticated IP reputation databases. They can tell the difference between a residential ISP address (likely a real user) and a datacenter IP (likely a bot or scraper). Even if the API key is valid, if the request originates from a "bad neighborhood" IP, it's blocked.

The Fix: Moving Beyond Public Endpoints

Trying to brute-force this with better user agents or rotating proxies is a losing game. Instead, I had to rethink the architecture:

1. Switch to OAuth Tokens: For Spotify, replacing the API key with a per-user OAuth token completely solved the problem. Since OAuth tokens are tied to actual user accounts, they bypass the IP-based reputation checks.
2. Session-Based Access: This meant restructuring the app to handle individual user sessions, storing tokens, and implementing refresh logic. It's more overhead, but it's the only way to get reliable access.
3. Alternative Methods: For YouTube Music, I gave up on the direct API and switched to using yt-dlp as a subprocess. It's robust and handles the video quality/audio extraction steps that the API lacks or blocks.

Lessons Learned

The days of slamming the "public" API of Spotify or Apple with a simple for-loop are over. These platforms are prioritizing user privacy and data integrity, which means they are actively blocking automated access patterns.

If you're building a music service, you need to:

• Implement OAuth for any provider where it's available.
• Respect rate limits and avoid hitting the API from a single static IP address.
• Consider local caching to minimize the number of requests you need to make.

The inconsistent behavior between platforms is frustrating, but the solution is the same: treat the API with the respect of a user rather than a script.